Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Is it possible you have a hold violation masqurading as a setup problem? The simulator being confused which clock edge the data was intended for and thus reporting the problem as a "setup time" problem. Regards "Hristo Stevic" <hristostev@yahoo.com> wrote in message news:<08784b3f07ff378d941fafb3063eb255.52609@mygate.mailgate.org>... > hello, > > Really i can't see why i am getting this error message > bram.clka too short setup time, missing time 2.3ns! > bram.clkb too short setup time, missing time 2.3ns! > > i am using bram in both read and write mode. the two ports are clocked > with the same clock, the master clock. one port is set always for > writing the other for reading. The address are always differents! > > the Bram address as well as the input data are REGISTRED, clocked with > the same clock clk > > so how can i get short setup time! i am using F3.1, sp7. > i have even set the data input to zero value, the same error happen, I > did timing simulation, the address values are as i expect (they change > the value after the clock rising edge) > > the we,en, rst bram inputs are set to VCC, or GND as required , the > input data are registred in the IOB, so really what i am missing ? why i > am getting this error? > > thanksArticle: 39376
There may have been nothing on the erratta directly, but I seem to remember chipscope wanted its own global clock, and the V2 samples that everyone was getting had something wierd with the clock routing- don't remember the details. Regards Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C5AB737.C3425BD3@xilinx.com>... > No errata on the errata sheet affects Chipscope ILA, > > I worked personally with one customer who was using it to resolve a design > issue on some 2V3000ES parts. > > If you need help, open a hotline case. > > Austin > > strut911 wrote: > > > hi. > > i am having trouble getting chipscope to run on the XC2V3000ES FG676 > > -5 part. i was wondering if this was a known issue with the samples or > > if it somehow has to do with my configuration. i have ran chipscope on > > the XC2V1000 parts with no problem (the Insight board) and i would > > really like to get it up on the 3000. > > strut911Article: 39378
yes, that sounds good. Altera is telling the same stuff for their MAX 7000 series EPM3032īs. The device cost is only $1 per piece. The problem is that you donīt get DIP package which still is the best for volume production and easy prototyping.Article: 39379
Hi, I'm looking for an RTL description or PLI module of the 8051 included in Triscend for simulation purposes. Thanks.Article: 39380
Bob Cain wrote:
>
> Rick Lyons wrote:
> >
> >
> > >I just wish there was some bonded credential I could get that stated
> > >"Bob Cain is not a student nor is he assisting one." :-)
> > >Bob
> >
> > Ah ha! That credential would be handy for a student
> > to have! Are you sure you're not a student Bob? ;-)
> > [Maybe a student of the 'School of Hard Knocks'.]
>
> I'll be a student in that school probably forever. :-)
>
> >
> > Yea, it happens. I once posted a question about
> > solving equations containing complex exponentials
> > whose real parts are non-zero. [e^(a +jb)]
> > Someone teased me that my question looked like
> > a homework problem, and that surprised/shocked
> > me. No matter though, 'cause then the fellow
> > proceeded to help me out for which I really was
> > grateful. The guy's answer forced me to stick my
> > toes in the chilly waters of hyperbolic functions.
> > Brrrrr!
>
> Yeah, that's what I mean. Even at my "advanced age" I still stumble
> across things like functional analysis and wavelets and Kolmogorov
> complexity where I know I've got yet another plunge that must be taken.
> Now what's this about hyperbolic functions? :-)
>
> Bob
> --
>
Try computing the attenuation along a DC transmission line without
hyperbolics. They will seem simple compared to the alternative ways. (I
learned about DC attenuation in order to design telegraph lines - aren't
all curricula outdated? - but nothing goes to waste: DC power
transmission is big these days, and the math hasn't changed.)
Jerry
--
Besides a mathematical inclination, an exceptionally good mastery of
one's native tongue is the most vital asset of a competent programmer.
Edsger W. Dijkstra
-----------------------------------------------------------------------
Article: 39381Ray Andraka <ray@andraka.com> writes: The following app note from Philips (prev. Signetics) might be of interest to start with. http://www.semiconductors.philips.com/acrobat/applicationnotes/AN219_1.pdf Arvin > It is not for glitches, it is for metastability resolution. Metastability > is a state between the legal 0 and 1 states that can be entered if the > flip-flop's data input changes right when the clock is clocking in the data > input. See the comp.arch.fpga FAQ (http://www.fpga-faq.com/) on > metastability. > > Richard Meester wrote: > > > Hello All, > > > > Why do you typically use 2 ffflops on a source signal to synchronize > > between 2 clocks with 2 different speeds. Has this to do with glitches? > > > > Could someone perhaps point me to a website which has good information > > about this topic. > > > > Thanks, > > > > Richard > > > > -- > > > > Quest Innovations > > tel: +31 (0) 227 604046 > > fax: +31 (0) 227 604053 > > http://www.quest-innovations.com > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759Article: 39382
It is pretty easy to contruct a state-machine to mimic the effects of a LFSR shift register that has been clocked an arbitrary number of times. To use your example the normal logic for X^3+X^2+1 using four flip-flops is: ff0=ff3^ff2^1 (xnor the last two flip-flops in the shift register) ff1=ff0 (shift) ff2=ff1 (shift) ff3=ff2 (shift) For each clock, the following design will produce the same four bit sequence produced by clocking the orignal design four times: ff0=ff3^ff2^ff0 (three term xor) ff1=ff1^ff0^1 (xnor) ff2=ff2^ff1^1 (xnor) ff3=ff3^ff2^1 (xnor) So the bit sequence for ff0 the upper design is: 0111011001010000111... The bit sequence for the four flip-flops on second design is: 3210 ---- 0111 0110 0101 0000 1110 ... I always called this generating pseudorandom in parallel. It is used a lot in communications work. Once you get the knack you can generate any sequence in any width. If you add flip-flops you can actually generate this sequence 8 bits at a time or even wider. JRC Ray Andraka <ray@andraka.com> wrote in message news:<3C62A21F.C8BFFA23@andraka.com>... > No. The neighboring bits, when taken a byte at a time from an LFSR are time shifted copies > of previous bits. If you take more than 1 bit per clock from an LFSR, you lose the uniform > white properties. Consider the 4 bit LFSR X^3+X^2+1: > > 0000 > 0001 > 0011 > 0111 > 1110 > 1101 > 1011 > 0110 > 1100 > 1001 > 0010 > 0101 > 1010 > 0100 > 1000 > 0000 > > Note that only the right most bit is random, the other bits are the same as the rightmost > but delayed by 1,2 and 3 clocks. If you use more than one bit per clock from an LFSR, you > wind up with a correlation that colors the output and destroys the uniform random > properties. The bottom line is that an LFSR at 100MHz produces a random BIT stream at 100 > MHz, not a byte stream. To get a random byte stream, you need to clock the LFSR 8 times > between samples so as to get new bit values (uncorrelated to any bits in previous sample) > in all 8 bits, which gives you a random byte stream of 100/8= 12.5 MHz. > > vt313@comsys.ntu-kpi.kiev.ua wrote: > > > In the LSFR bitstream the bytes of neighboring bits, > > considered as signed vectors, are practically > > uncorrelated, and belong to the interval (-1.0 : 1.0). > > Therefore LSFR generator at 100 MHz > > provides the byte stream at 100 MHz. > > > > If you add couples of neigboring > > sampling bytes from LSFR, > > then you get the approximation > > of the "triangle" distribution. > > > > If you want the Gaussian distribution, > > then you would add n>10 neigboring > > sampling bytes from LSFR, > > and get the rather exact approximation > > of the Gaussian distribution. > > > > Anatoli S. > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759Article: 39383
I have a verilog design that was targetted for the virtex 600e device. Using the foundation ISE version 3.3 tools (servicepack 8), I ran the place and route tools with some timing constraints, and the design was successfully routed with 0 timing violation. The hardware prototype worked perfectly. 2 weeks ago, I decided to upgrade my tools to version 4.1. After the upgrade, I ran the same design through version 4.1 and got a whole list of timing violations (some constraints are violated due to gate delays alone). I called the Xilinx tech hotline, and they said that the timing library for version 4.1 reflects the characteristics of the latest silicon. He told me sorry for the inconvenience- I should either relax the constraints (not possible) or redesign the circuit (or face the possibility that the circuit may fail). Apparently, I would never have realise this problem if I did not upgrade my tools. According to Xilinx tech support, the big timing difference between ver 3.3 & 4.1 affects all the virtex E devices. I am sure I am not the only person with this problem. If you have a virtexE design in production PAR with ISE 3.3, what have/would you do? Thanks.Article: 39384
Has anyone heard of Schema Schematics capture ? I have the behavioral model, schema netlist, and Lux FPDL netlist for an ASIC and need to convert it into VHDL. Any pointers ? Does the Schema uses the behavioral models as part of the schematics and then gets converted by the Lux FPDL into RTL ? Any help will be appreciated. AngelArticle: 39385
"Antonio" <dottavio@ised.it> wrote in message
news:fb35ea96.0201032335.7ab30bd8@posting.google.com...
> I've the problem that with the following code I can't obtain an output
> from the ROM when the address is all zeroes, pratically I obtain UUU
> instead of a value 49E located in ROM_SRRCx3(0), may be that
> conv_integer is not working for this value ?? What is the solution ??
>
>
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_signed.all;
> use ieee.std_logic_arith.all;
> use std.textio.all;
> use work.SRRC_coeffs.all;
>
> entity ROMx3 is
> port(reset : in STD_LOGIC ;
> clk : in STD_LOGIC ;
> --load : in STD_LOGIC ;
> fir_sel : in STD_LOGIC_VECTOR(2 downto 0);
> addr_6 : in STD_LOGIC ;
> addr_5 : in STD_LOGIC ;
> addr_4 : in STD_LOGIC ;
> addr_3 : in STD_LOGIC ;
> addr_2 : in STD_LOGIC ;
> addr_1 : in STD_LOGIC ;
> addr_0 : in STD_LOGIC ;
>
> SRRC_out : out STD_LOGIC_VECTOR(11 downto 0));
> end;
>
> architecture ROMx3_arch of ROMx3 is
> begin
> process(clk, reset)
> begin
> if( reset = '1' ) then
> SRRC_out <= "000000000000";
> elsif falling_edge(clk) then
> SRRC_out <= ROM_SRRCx3( conv_integer(fir_sel & addr_6 & addr_5 &
> addr_4 & addr_3 & addr_2 & addr_1 & addr_0) );
> end if;
> end process;
> end ROMx3_arch;
Antonio,
I have used similar which worked. I am a starter in fpga field.
I worked with a following code.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
entity SCRAMBLING_RAM is
port(
ADDRESS : IN std_logic_VECTOR(2 downto 0);
SCR_BYTE : OUT std_logic_VECTOR(7 downto 0)
);
end SCRAMBLING_RAM;
architecture SCRAMBLING_RAM_ARCH of SCRAMBLING_RAM is
type MEM is array (0 to 8) of std_logic_vector(7 downto 0);
signal ramTmp : MEM;
begin
ramTmp(0) <= "11111110";
ramTmp(1) <= "00000100";
ramTmp(2) <= "00011000";
ramTmp(3) <= "01010001";
ramTmp(4) <= "11100100";
ramTmp(5) <= "01011001";
ramTmp(6) <= "11010100";
ramTmp(7) <= "11111010";
ramTmp(8) <= "00011100";
SCR_BYTE <= ramTmp(Conv_integer(ADDRESS)) ;
end SCRAMBLING_RAM_ARCH;
Madhu
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Article: 39386
Exactly. In fact, all the LFSR is is a special case of the CRC hardware. I did't want to
confuse the issue, but as you say, you can create a parallel version of the LFST that appears at
the outputs to advance N clocks in a single clock.
jrc wrote:
> It is pretty easy to contruct a state-machine to mimic the effects of
> a LFSR shift register that has been clocked an arbitrary number of
> times. To use your example the normal logic for X^3+X^2+1 using four
> flip-flops is:
>
> ff0=ff3^ff2^1 (xnor the last two flip-flops in the shift register)
> ff1=ff0 (shift)
> ff2=ff1 (shift)
> ff3=ff2 (shift)
>
> For each clock, the following design will produce the same four bit
> sequence produced by clocking the orignal design four times:
>
> ff0=ff3^ff2^ff0 (three term xor)
> ff1=ff1^ff0^1 (xnor)
> ff2=ff2^ff1^1 (xnor)
> ff3=ff3^ff2^1 (xnor)
>
> So the bit sequence for ff0 the upper design is:
>
> 0111011001010000111...
>
> The bit sequence for the four flip-flops on second design is:
>
> 3210
> ----
> 0111
> 0110
> 0101
> 0000
> 1110
> ...
>
> I always called this generating pseudorandom in parallel. It is used a
> lot in communications work. Once you get the knack you can generate
> any sequence in any width. If you add flip-flops you can actually
> generate this sequence 8 bits at a time or even wider.
>
> JRC
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3C62A21F.C8BFFA23@andraka.com>...
> > No. The neighboring bits, when taken a byte at a time from an LFSR are time shifted copies
> > of previous bits. If you take more than 1 bit per clock from an LFSR, you lose the uniform
> > white properties. Consider the 4 bit LFSR X^3+X^2+1:
> >
> > 0000
> > 0001
> > 0011
> > 0111
> > 1110
> > 1101
> > 1011
> > 0110
> > 1100
> > 1001
> > 0010
> > 0101
> > 1010
> > 0100
> > 1000
> > 0000
> >
> > Note that only the right most bit is random, the other bits are the same as the rightmost
> > but delayed by 1,2 and 3 clocks. If you use more than one bit per clock from an LFSR, you
> > wind up with a correlation that colors the output and destroys the uniform random
> > properties. The bottom line is that an LFSR at 100MHz produces a random BIT stream at 100
> > MHz, not a byte stream. To get a random byte stream, you need to clock the LFSR 8 times
> > between samples so as to get new bit values (uncorrelated to any bits in previous sample)
> > in all 8 bits, which gives you a random byte stream of 100/8= 12.5 MHz.
> >
> > vt313@comsys.ntu-kpi.kiev.ua wrote:
> >
> > > In the LSFR bitstream the bytes of neighboring bits,
> > > considered as signed vectors, are practically
> > > uncorrelated, and belong to the interval (-1.0 : 1.0).
> > > Therefore LSFR generator at 100 MHz
> > > provides the byte stream at 100 MHz.
> > >
> > > If you add couples of neigboring
> > > sampling bytes from LSFR,
> > > then you get the approximation
> > > of the "triangle" distribution.
> > >
> > > If you want the Gaussian distribution,
> > > then you would add n>10 neigboring
> > > sampling bytes from LSFR,
> > > and get the rather exact approximation
> > > of the Gaussian distribution.
> > >
> > > Anatoli S.
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930 Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 39387worrying isn't it ! In the past I've generally found that the speed files have become less pessimistic as Xilinx have refined them, so the chips 'get faster'. No excuse for this though as I thought 3.3 sp8 virtexE speedfiles were final ? there is a Xilinx utility (speedprint) which prints out the timing details for a device from a speedfile - I'll compare 3.1 sp 8 and 4.1. sp2 tomorrow. In my experience 4.1 generally gives a faster result than 3.3 for the same code & virtex E device, however in your particular case it may be that the tool is doing a worse job ? Mike "Jui Tan" <juitongtanSPAM@yahoo.com> wrote in message news:1013117951.597749@hp-sdd.sdd.hp.com... > I have a verilog design that was targetted for the virtex 600e device. > Using the foundation ISE version 3.3 tools (servicepack 8), I ran the place > and route tools with some timing constraints, and the design was > successfully routed with 0 timing violation. The hardware prototype worked > perfectly. > > 2 weeks ago, I decided to upgrade my tools to version 4.1. After the > upgrade, I ran the same design through version 4.1 and got a whole list of > timing violations (some constraints are violated due to gate delays alone). > I called the Xilinx tech hotline, and they said that the timing library for > version 4.1 reflects the characteristics of the latest silicon. He told me > sorry for the inconvenience- I should either relax the constraints (not > possible) or redesign the circuit (or face the possibility that the circuit > may fail). > > Apparently, I would never have realise this problem if I did not upgrade my > tools. According to Xilinx tech support, the big timing difference between > ver 3.3 & 4.1 affects all the virtex E devices. > > I am sure I am not the only person with this problem. If you have a virtexE > design in production PAR with ISE 3.3, what have/would you do? > > Thanks. > >Article: 39388
Hi Srini, I tried the newest Leon code (2.4.0) and the one I used to use on a regular basis (2.2 I think). Both of them compile and simulate fine. I have tried the main testbench as well as the various configurations supplied. The problem could be specific to WinXP (very unlikely). If you can send me the exact vhdle command line which demonstrates the problem, I will have it resolved as soon as possible. Regards, Haneef PS: Can you please respond directly to me. Once we have things resolved, we can report back to the group.Article: 39389
"Jui Tan" <juitongtanSPAM@yahoo.com> wrote in message
news:1013117951.597749@hp-sdd.sdd.hp.com...
> I have a verilog design that was targetted for the virtex 600e
> device. Using the foundation ISE version 3.3 tools (servicepack 8),
> I ran the place and route tools with some timing constraints, and
> the design was successfully routed with 0 timing violation. The
> hardware prototype worked perfectly.
>
> 2 weeks ago, I decided to upgrade my tools to version 4.1. After
> the upgrade, I ran the same design through version 4.1 and got a
> whole list of timing violations (some constraints are violated due
> to gate delays alone). I called the Xilinx tech hotline, and they
> said that the timing library for version 4.1 reflects the
> characteristics of the latest silicon. He told me sorry for the
> inconvenience- I should either relax the constraints (not possible)
> or redesign the circuit (or face the possibility that the circuit
> may fail).
>
> Apparently, I would never have realise this problem if I did not
> upgrade my tools. According to Xilinx tech support, the big timing
> difference between ver 3.3 & 4.1 affects all the virtex E devices.
>
> I am sure I am not the only person with this problem. If you have
> a virtexE design in production PAR with ISE 3.3, what have/would you
> do?
>
> Thanks.
Jui,
Not all the problems with 3.3i sp8 or before were due to poor device
characterization. We use the 1000e-7 and there was a bug in the timing
analysis, either in the speed file or in the software. In our case, the
WEAs for BlockRAMs in column 0 (RxC0.WEA) had phenomenal(!) timing.
A single net went to the WEA of all 16 BlockRAMs in column 0 and
several BlockRAMs in other columns. The net delays to the other BlockRAMs
looked sensible, and indeed they matched when comparing timing analysis
for the routed design using 3.3i sp8 and 4.1i sp2.
However, the delays reported for the net as it traveled down C0 were
a little optimistic (sarcasm) with 3.3i sp8. From row 0 to row 15 the net
showed a delay of 5 ps. Yes, 5 picoseconds. The row-to-row delta was either
0 ps or 1 ps. (We could only hope for such timing!)
4.1i sp2 showed something a little different. The row-to-row delay was
consistently 392 ps or 393 ps, so the total net delay from row 0 to row 15
was 5.885 ns.
I would never have found this nor suspected it except we had a failure
in the lab and I happened to have upgraded the tools since the build. I
ran timing analysis using 4.1i sp2 and was a little surprised to see
timing violations. (There were 0 errors and 0 unconstrained paths with
3.3i sp8.) I looked at the nets and this WEA was the worst violator.
Comparing 3.3 to 4.1 it was obvious what the problem was. And the failure
in the lab was associated with the BlockRAM at row 15, which had the most
grossly underestimated delay. Case closed: 3.3 with its speed file is
bad. I never tried running 3.3 sp8 with a newer speed file, so I can't
say for sure whether it's a software problem ("let's zero out the delays
for BlockRAM column 0"--oops) or a speed file problem.
Now to your question. If you can verify margin in your system
(operating temperature or voltage) I'd take that into account and see if
you're still missing timing. Then, and this is as risky as design gets,
I'd try to rationalize how much faster the parts are than what the timing
reports say. If you're using the -8, there may not be a lot of margin,
and you should think about recalling your hardware. In the meantime, see
if you can get a clean build using 4.1i, because that's what you'll want
to use going forward.
Not all designs can justify a network connection or the hardware that
supports upgrading over the Internet, but it is worth considering for
situations like this.
Good luck,
Marc Klingelhofer
Article: 39390Hi - You pose a good question. I can't give you a complete answer, but perhaps I can suggest a few things. Quite a while ago, Xilinx put in place a system for categorizing speed files which, if I recall correctly, goes like this: advanced - speed files based on SPICE simulations, educated guesses, etc. preliminary - speed files based on early silicon final - speed files based on production silicon I assume that Xilinx still uses this system, or something similar (can someone from Xilinx confirm or correct?). This nomenclature is fairly common practice in the industry, although company X and company Y may disagree on the specifics of what constitutes a given category. If you're designing an FPGA and the speed files are advanced or preliminary, do two things: 1) Design in some timing margin by decreasing the timespecs. For example, if your clock is supposed to run at 100MHz, make your period target 8 or 9ns instead of 10. If you can't meet the faster specs, you may have to rethink your design. (Case in point: I've been working on a Virtex II design, and I created twice as many datapaths as the initial timing specs seemed to indicate were necessary, and ran them at half speed. It was a lot of trouble, but when the Virtex II multiplier specs took a significant speed hit a few months ago, I was very glad I did it.) 2) Do NOT design with the fastest speed grade; save it to dig yourself out of trouble if the unthinkable happens. What to do about products that have already shipped is a tough call. If you've put 100% of your outgoing units through 4-corner environmental test (i.e., voltage and temperature extremes), you should be OK. If not, you may have to come up with an alternative design, perhaps in a faster speed grade, to replace those units that are returned. Bob Perlman -- Cambrian Design Works digital design, signal integrity http://www.cambriandesign.com e-mail: respond to bob at the domain above. On Thu, 7 Feb 2002 13:39:05 -0800, "Jui Tan" <juitongtanSPAM@yahoo.com> wrote: >I have a verilog design that was targetted for the virtex 600e device. >Using the foundation ISE version 3.3 tools (servicepack 8), I ran the place >and route tools with some timing constraints, and the design was >successfully routed with 0 timing violation. The hardware prototype worked >perfectly. > >2 weeks ago, I decided to upgrade my tools to version 4.1. After the >upgrade, I ran the same design through version 4.1 and got a whole list of >timing violations (some constraints are violated due to gate delays alone). >I called the Xilinx tech hotline, and they said that the timing library for >version 4.1 reflects the characteristics of the latest silicon. He told me >sorry for the inconvenience- I should either relax the constraints (not >possible) or redesign the circuit (or face the possibility that the circuit >may fail). > >Apparently, I would never have realise this problem if I did not upgrade my >tools. According to Xilinx tech support, the big timing difference between >ver 3.3 & 4.1 affects all the virtex E devices. > >I am sure I am not the only person with this problem. If you have a virtexE >design in production PAR with ISE 3.3, what have/would you do? > >Thanks. >Article: 39391
whazzup wrote: > yes, that sounds good. Altera is telling the same stuff for their MAX 7000 series EPM3032īs. The device cost is only $1 per piece. The problem is that you donīt get DIP package which still is the best for volume production and easy prototyping. It was a long time ago, still in the DIP era, when we made the decision that its really not worth making up wire-wrap proto boards - just do the real thing. With that in mind and the fact that the XC95K parts are in system reprogrammable the DIP argument falls. And for volume production auto pick&place pure SMT boards reduce assembly costs.Article: 39392
Thanks for the replies, Looks like they're throw aways. They were removed (socketed) from old boards so I don't know the source. As I have a well stocked junk box, I thought the programmer would be easy and cheap, but obviously with controlled rise times - maybe not. James. Victor Schutte wrote: > I agree. The cost of a couple of 7064Ss and a homemade ByteBlaster cable is > a lot less than an Altera programmer. > > Victor > > "Jim Granville" <jim.granville@designtools.co.nz> wrote in message > news:3C60C6D5.48CB@designtools.co.nz... > >>James wrote: >> >>>Hi, >>> >>>just scored some used, but reusable EPM7064 gate arrays that I would >>> > like to > >>>use in some home projects. Unfortunately they are NOT "in circuit >>>programmable" and require a seperate programmer. >>> >>>The Altera web site has no details on programming these devices, but do >>> > have > >>>free software for circuit entry etc. >>> >>>Can a programmer be built by me for these parts (I don't need high speed >>> > or > >>>flexibility)? Obviously my budget doesn't allow for a bought one - >>> > unless > >>>extremely cheap (few 10s of $), else I'd just buy one. >>> >>>Does anyone know where programming details can be found? Surely such >>> > details > >>>are freely available! >>> >>No, because the support is too costly. It wont work first time, and then >>what happens... >> >>You might find an old programmer that supports the non-isp models, but >>better >>is to move to ISP CPLDs >> >>In this class of CPLD are >> >>Altera 7064S - newer ISP versions of those you have >>Xilinx CoolRunner XCR3064 >>Atmel ATF1504AS >> >>Atmel have the best 5V support. >> >>-jg >> > >Article: 39393
Thanks all for the pointers. Richard Arvin Patel wrote: > Ray Andraka <ray@andraka.com> writes: > > The following app note from Philips (prev. Signetics) might be of interest > to start with. > > http://www.semiconductors.philips.com/acrobat/applicationnotes/AN219_1.pdf > > Arvin > > > It is not for glitches, it is for metastability resolution. Metastability > > is a state between the legal 0 and 1 states that can be entered if the > > flip-flop's data input changes right when the clock is clocking in the data > > input. See the comp.arch.fpga FAQ (http://www.fpga-faq.com/) on > > metastability. > > > > Richard Meester wrote: > > > > > Hello All, > > > > > > Why do you typically use 2 ffflops on a source signal to synchronize > > > between 2 clocks with 2 different speeds. Has this to do with glitches? > > > > > > Could someone perhaps point me to a website which has good information > > > about this topic. > > > > > > Thanks, > > > > > > Richard > > > > > > -- > > > > > > Quest Innovations > > > tel: +31 (0) 227 604046 > > > fax: +31 (0) 227 604053 > > > http://www.quest-innovations.com > > > > -- > > --Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com > > > > "They that give up essential liberty to obtain a little > > temporary safety deserve neither liberty nor safety." > > -Benjamin Franklin, 1759 -- Quest Innovations tel: +31 (0) 227 604046 fax: +31 (0) 227 604053 http://www.quest-innovations.comArticle: 39394
Hi Ray,
the problem is synchronization between the data arriving from the
pattern generator and the clocks that are inside FPGA, my idea to use
clkdll was to enter inside the FPGA with the clock (25MHz for example)
associated to the data and coming from the pattern generator, from
that clock to obtain a 100MHz master clock via the CLKDLL and in this
way is all synchronized, but 100MHz out of the DINI board seems to be
not achieved.
If I choose your schema 40MHz quartz plus clkdll divider, I've the
problem that this divided frequency, maybe 10MHz is not synchronized
to the 10 MHz coming from the pattern generator, about this I'm
studing the opportunity to insert a FIFO which write is driven from
the pattern generator clock and read is driven from the board reduced
clock.
What do you think about this, there's a simple way to obtain the same
results ??
Antonio
Article: 39395
Hi Peter et al,
I wish to use a DCM as a programmable and sweepable clock source
within a Vertex2 device. It will only be supplying its output to an
external pin,
but the output will need to be gatable.
I want to use it in the Digital Frequency Synthesis mode, with registers to
hold
the Multiplier & Divider values so that the output frequency can be changed
at
any time. The only problem I have is that I cannot find the M & D control
signals
on the instance of the DCM block. I believe that I will need to use the
CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it
is instanced, but I am not clear how I can use these in a dynamically
adjustable way.
Can anyone tell me if this is possible, and if so, a little snippet of
Verilog to illustrate?
(pretty please)
Thanks,
Tim Ottley.
Article: 39396yes, you have all discovered my secret. i wish to sell solutions manuals over the internet, especially the manuals to complex graduate algorithmic books. i have seen the potential and it is huge. it completely dwarfs my asic design salary (which is not that much at all by the way). in this way, i can undermine the whole engineering education system, and throw the world, nay, the universe to a time when technology was just an apple falling on newton's head. far be it from me to actually try and work out a textbook problem by problem and learn something. that is for sissies. real men are the ones that can walk a tightrope without a net, drive a car without a seat belt. unfortunately, i was hoping that mummy would hold my hand, and unfortunately, i discovered that mummy doesn't exist. and so, i will pursue my solutions manuals on amazon.com and search for them through hotbot and other metasearch engines. when i do come across interesting engineering manuals and am tempted to buy the book, i might have the inclination to suspect myself of trying to cheat on the midterm i give myself or my personal take-home final. maybe i will collaborate with myself on my homework, or copy my own answers. hmmm...i can understand how suspicious my actions are. i am, after all, trying to grab a chunk of that huge engineering technical reference book pie that has made many a professor rich and famous. strut911 p.s. i hope no one takes offense at this. i really enjoyed reading the responses.Article: 39397
On Wed, 06 Feb 2002 21:05:49 -0800, Bob Cain <arcane@znet.com> wrote: (snipped) >Now what's this about hyperbolic functions? :-) > >Bob Ah, I was tryin' to derive the equation for the frequency response of an IIR filter having poles lying just inside the unit circle. I ended up with terms like (1 + Ke^jw), where K was just less than unity. As my algebra plodded along I ended up with terms like e^(x+jw), a complex exponential with a non-zero real part in the exponent, and that's when I needed help. [-Rick-]Article: 39398
On Thu, 07 Feb 2002 14:14:00 -0500, Jerry Avins <jya@ieee.org> wrote: (snipped) >I learned about DC attenuation in order to design telegraph lines - aren't >all curricula outdated? - but nothing goes to waste: DC power >transmission is big these days, and the math hasn't changed.) > >Jerry Telegraph lines!! Maybe I was right when I once posted that you knew Abraham Lincoln personally. [-Rick-]Article: 39399
On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com> wrote:
>Hi Peter et al,
>
>I wish to use a DCM as a programmable and sweepable clock source
>within a Vertex2 device. It will only be supplying its output to an
>external pin,
>but the output will need to be gatable.
>
>I want to use it in the Digital Frequency Synthesis mode, with registers to
>hold
>the Multiplier & Divider values so that the output frequency can be changed
>at
>any time. The only problem I have is that I cannot find the M & D control
>signals
>on the instance of the DCM block. I believe that I will need to use the
>CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it
>is instanced, but I am not clear how I can use these in a dynamically
>adjustable way.
>
>Can anyone tell me if this is possible, and if so, a little snippet of
>Verilog to illustrate?
>(pretty please)
>
>Thanks,
> Tim Ottley.
>
This is do-able, but FAR from easy. The M and D values are parameters
that end up being encoded in the bit stream. There is no direct runtime
access to them.
The Virtex-II devices do support run-time partial configuration.
You would need to find the location of these bits in the bitstream,
and create a partial reconfig to modify them on the fly. Given the
issues with DCM reset, I would suspect that to be succesful, you would
need to assert the DCM reset, then do the reconfig, then release DCM
reset. Since configuration is by frames, you would also have to build
reconfiguration frames that did not damage other parts of your design.
So I dont think that sweeping is going to be possible.
To see what you are up against, create a design with a DCM in it.
and create an RBT file from it. Using the XDL interface to the
NCD file, edit the M and D, convert back to NCD and create a new
RBT. Compare to see how it changed.
In the XDL, look for something like this:
inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 ,
cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW
STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE
FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2
FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF
STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF
PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC
RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF
CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF
CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF
CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE
CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF
DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4
PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS::
LL_HEX_COM:: LL_HEX_MISC::"
M and D are on the third last line. BUT ... there seems to be
quite a few other attributes that are being automatically set
by the sw, that are not documented for user control.
The command I used to create the above was:
xdl -ncd2xdl app_1.ncd
I am using M4.1i sp3
Good luck,
Philip Freidin
Philip Freidin
Fliptronics
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z