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
You want a limited set multiplier. Look at the multiplier page ( http://users.ids.net/~randraka/multipli.htm ) on my website, it tells you what you need to know for the construction. It will be up to you to translate that to VHDL. If you describe it at the circuit level, the translation is pretty easy. Bonio Lopez wrote: > Sorry, I must correct small error in my first message(I have not typed > word multiply): > .... > I want to paralell MULTIPLY (in FPGA) only this 5 integers with > only... > > * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * > The fastest and easiest way to search and participate in Usenet - Free! -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18851
Be careful clocking SDRAMs slow. Some of the DDR SDRAMs have minimum clock period specs which must be met to prevent data loss, and 33MHz is below that spec for some parts. Andy Peters wrote: > You also need to remember that even though your read and write duty cycles > may be very low, you must still talk to the SDRAM module at the clock speed. > However, there's no law saying that you must run PC100 modules at 100 MHz. > You can run them at 33 MHz if you like. > > You're asking about the SDRAM timing parameters. You must understand them > in order to use SDRAMs. Parameter #1, of course, is the clock frequency, > which should be obvious. Parameter #2 is the "CAS latency" (also called > read latency). This is the delay between registration of the READ command > and the availability of first data word. It's usually two or three clock > cycles, depending on the clock speed (a higher clock speed may require an > extra clock cycle). There's also a latency from the time you activate > (OPEN) a row to the time you are allowed to assert a command; sometimes it's > one tick, or two if the clock speed is fast. > > You should check out the SDRAM data sheets at Micron's web site. They're > large (50 pages) but you really need to understand how the parts work before > attempting a design with them. They're not necessarily difficult, just > idiosyncratic. > > a > > -- > ----------------------------------------- > Andy Peters > Sr Electrical Engineer > National Optical Astronomy Observatories > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) noao \dot\ edu > > "Creation Science" is oxymoronic. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18852
glen herrmannsfeldt writes: > Well, say you implement a simple processor, either existing or new, > on the FPGA and then write code for it. Maybe even a C compiler and > compile an existing implementation. Much easier if it is just UDP, but > if the code is in ROM or RAM then even TCP shouldn't be hard. I worked for a while on a TCP implementation without using a processor. Unfinished, just enough to do ARP and some header parsing. I have been told of a small HTTP server on an FPGA. I don't know if they built a processor or not, and I will try to find references. Curiously people don't seem to want to talk.. -- JamieArticle: 18853
Hello, are you a Hardware Engineer? An EE student? Are you a VHDL/Verilog HDL coder? Are you bored with your day-to-day job? Then help us with our open IP cores projects. We are trying to design and build several different cores, from microprocessors to various peripherals. All cores will be published at http://www.opencores.org. Visit us at http://www.opencores.org. regards, opencores.org teamArticle: 18854
Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote in article <81197a$12u4$1@noao.edu>... > Austin Franklin wrote in message <01bf318a$fc7c84d0$207079c0@drt1>... > > > >> Don't instantiate the startup block. Just make sure that the reset > >signal > >> goes to EVERY SINGLE FLIP-FLOP IN YOUR DESIGN, and your synthesis tool > >> should infer GSR. If it does not, you should get a message saying that > >it > >> was not inferred, and you'll have to look at the synthesis report to see > >> which flops were not included. > > > >That sounds tedious, probably un-necessary and may be even not right. Why > >not just do it this way: > > > >STARTUP_VIRTEX startup_virtex ( > > .GSR (I_RESET), > > .GTS (I_TS), > > .CLK (1'b0) > > ); > > No, neither tedious or unnecessary. And it is right. When I write code > that's supposed to end up as a flipflop, I always include an async reset > that uses the GSR. That takes care of the power-on reset. If a flip has to > be (re)set any time other than at power-up, I use a synchronous reset. It shouldn't be any different to do reset 'correctly' for an HDL design or a schematic design, so I will ignore any problems that may exist with using HDLs. This is an architecture issue, not a tool issue. How can you say intentionally adding a reset to EVERY flop in the design is not tedious? Adding code to every instance of a flip flop in the design is certainly extra work. How is it necessary? If the GSR resets every flop, and is on a global dedicated net that doesn't even take up any resources (that can be used for something else), and meets timing and operational requirements? What are you talking about power on reset? You don't have to do anything for power on reset, it is inherent in the configuration process. The data sheet says (and I quote): "The default Start-up sequence is that one CCLK cycle after DONE goes High, the global tri-state signal (GTS) is released. This permits the device outputs to turn on as necessary. One CCLK cycle later, the Global Set/Reset (GSR) and Global Write Enable (GWE) signals are released. This permits the internal storage elements to begin changing state in response to the logic and the user clock." It also goes on to say it may be paused until DLL lock has been achieved. So, given this, I don't understand what or why it is you believe you have to do special for power-on reset. Now, on creating a 'special' net for use as a reset (instead of using the inherent GSR). The Virtex spec says the delay from GSR to XQ/YQ is under 10ns. You say you assert your RESET to the part synchronously, so as long as your clock frequency is not > 100MHz, you will not have any problems using the dedicated global reset, and therefore, is unnecessary to do it using non-dedicated resources in this regard. The delay from SR to XQ/YQ is 1.1. Using one of the secondary global nets (you can't use a primary, they only go to clock pins) the delay from the pad to the SR seems to easily be as high as the dedicated GSR routing, depending on how far from the input buffer. I only had around 64 flops in the design, and they were not very far away, and I saw delays as high as 6+ns, and it burns a LOT of resources. So, with a VERY small design, I am seeing a delay using a secondary global net of 7.2ns. I had a MAXDELAY and a MAXSKEW on the RESET net. So, in some instances is MAY be faster, then again, not, but will only give you any benefit if you are running over 100MHz. If you have an asynchronous reset, then all bets are off with either method, no matter how low your RESET delay and/or skew is inside your part, you stand a chance of having some of the chip come out of RESET on a different clock edge...so you have to design accordingly, which is not too tough to do, but still does not warrant not using the GSR. So, it would also appear that using anything aside from the dedicated GSR would not give you any benefit (except under very specific conditions), and therefore, at least for my designs, unnecessary. And given the extra resources it would use, I would also call it 'wrong'. I would appreciate it if you would post some 'facts' as to WHY creating your own RESET signal, instead of using the dedicated GSR RESET signal, is somehow beneficial.Article: 18855
> On power-up the registers initial values are all defined by the configuration > program. GSR is indeed too slow for use in higher performance designs. ... Speaking of GSR being slow, that brings up the whole Metastability mess again. This probably isn't statistically important since GSR doesn't change very often. Note that even if you have plenty of time, you can't use GSR to reset the whole chip if you have two or more asynchronous clocks. At least you can't do it cleanly. Even if you only have one clock, you also have to make sure that the signal connected to GSR is clocked by that clock rather than a junk IO from a microprocessor that's running on a different clock. -- These are my opinions, not necessarily my employers.Article: 18856
Jamie Lokier <spamfilter.nov1999@tantalophile.demon.co.uk> wrote in message news:m2zowbs1bx.fsf@pcep-jamie.cern.ch... > glen herrmannsfeldt writes: > I worked for a while on a TCP implementation without using a processor. > Unfinished, just enough to do ARP and some header parsing. > > I have been told of a small HTTP server on an FPGA. I don't know if > they built a processor or not, and I will try to find references. But when do you start calling it a processor (or not...)? A lot of good sized state machines I've seen start to look an awful lot like a microsequencer, and from there it's just a hop, skip, and a jump until you decide you're just going to have "this ROM" (that just so happens to be a RAM in an FPGA...) that stores microcode and could start to have your "hardware TCP/IP implementation" compute Pi or crack DES in its spare time... If Wade Peterson is around, he can let us know how much of something like a Virtex XCV400 his PIC-compatible core takes. I bet it's something under 10%. ---Joel KolstadArticle: 18857
Hi to all!
My end-goal is to port my ISA card design to PCI. This ISA card is a
simple 8255-based I/O board. It's details if you are interested are at
http://www.boondog.com - see the Tutorials link.
I have no PCI experience. My impression is that one needs a FPGA or other
programmable logic device (PLD) for PCI interfacing.
I have no PLD experience but do know digital logic and digital system
design (I am mechanical engineer).
Xilinx and Altera sell affordable ($100 range) development kits and
software (student versions).
Q. For my stated end-goal which PLD should I begin my learning curve on?
Q. Are on-line PCI tutorials (in relation to my end-goal or porting
ISA designs to PCI) ?
Much appreciated,
Paul Oh
Article: 18858Joel Kolstad writes: >> I have been told of a small HTTP server on an FPGA. I don't know if >> they built a processor or not, and I will try to find references. > But when do you start calling it a processor (or not...)? Well it is a processor of course. It's not a CPU. I'd call it a CPU when you make a point of building a CPU and programming it (or the hardware compiler does that for you). > A lot of good sized state machines I've seen start to look an awful > lot like a microsequencer, and from there it's just a hop, skip, and a > jump until you decide you're just going to have "this ROM" (that just > so happens to be a RAM in an FPGA...) that stores microcode and could > start to have your "hardware TCP/IP implementation" compute Pi or > crack DES in its spare time... None of the network applications I've implemented on FPGAs could be easily changed to compute Pi or crack DES. And the unfinished TCP/IP thing did not have a program ROM/RAM. You could add a Pi computer or DES cracker running in parallel though... > If Wade Peterson is around, he can let us know how much of something like a > Virtex XCV400 his PIC-compatible core takes. I bet it's something under > 10%. I once implemented a stack CPU on an Altera 10K20 in <"300 gates". A pain to program, but you can make these things very small. -- JamieArticle: 18859
Andy Peters wrote: > You should check out the SDRAM data sheets at Micron's web site. They're > large (50 pages) but you really need to understand how the parts work before > attempting a design with them. They're not necessarily difficult, just > idiosyncratic. On the same site Micron also have some nice Verilog & VHDL simulation models of their SDRAMs that might also help in understanding some of the more obscure timing parameters.Article: 18860
On Thu, 18 Nov 1999 08:42:09 -0500, Ray Andraka <randraka@ids.net> wrote: > In an >FPGA, you want to try to do strategic resets rather than global resets to >leave routing open for other signals, and more importantly to keep from >dragging your maximum clock frequency down into the weeds. See my previous >post in this thread for more detail. Agreed, but it's often not so bad that you have to worry about this. If you're using a synth, then it will duplicate highly-loaded nets. Spectrum tends to produce fanouts of 30 or 40 by default, and in large synchronous reset nets I've seen maximum net delays of about 12ns on a Virtex-4. And if you're worried, of course, then you should constrain the reset to a secondary clock buffer, which will give much better performance and routing. EvanArticle: 18861
On Thu, 18 Nov 1999 09:23:09 -0700, "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> wrote: >No, neither tedious or unnecessary. And it is right. When I write code >that's supposed to end up as a flipflop, I always include an async reset >that uses the GSR. That takes care of the power-on reset. If a flip has to >be (re)set any time other than at power-up, I use a synchronous reset. Or power-on preset, of course - try doing that without an explicit GSR signal. I had an interesting problem recently. I generated a GSR signal combinatorially, calling it GSR_H, and connected it to the GSR pin on a STARTUP_VIRTEX, as well as using GSR_H explicitly in my code (my personal preference is to do both). The synth duplicated GSR_H, because of its high fanout, generating a number of GSR_H_* nets, each sourced by a LUT3. However, the mapper saw only GSR_H itself connected to the STARTUP_VIRTEX, and so it removed the explicit connections on GSR_H, but *not* the connections on the duplicated GSR_H_* nets. So I ended up with maybe 90% of the GSR net explicitly routed, as well as using the real GSR itself. It was easily fixed, but I only spotted it by accident in FPGA editor. EvanArticle: 18862
Hi, the following problem occured: I wrote a fsm in vhdl (foundation software) and it works fine. The hardware, where the fpga in used in, does not offer a "real" reset signal. How can I bring my fsm into a specific reset state after booting the fpga ? Can StartUp help me ? MatthiasArticle: 18863
> I had an interesting problem recently. I generated a GSR signal > combinatorially, calling it GSR_H, and connected it to the GSR pin on > a STARTUP_VIRTEX, as well as using GSR_H explicitly in my code (my > personal preference is to do both). Why? What do you think that buys you?Article: 18864
12 ns is all well and good, unless you have clock frequencies that are well above 100MHz as are a large majority of my recent designs. Virtex-4 is quite capable of system clock speeds in excess of 100 MHz with careful design. eml@riverside-machines.com.NOSPAM wrote: > On Thu, 18 Nov 1999 08:42:09 -0500, Ray Andraka <randraka@ids.net> > wrote: > > > In an > >FPGA, you want to try to do strategic resets rather than global resets to > >leave routing open for other signals, and more importantly to keep from > >dragging your maximum clock frequency down into the weeds. See my previous > >post in this thread for more detail. > > Agreed, but it's often not so bad that you have to worry about this. > If you're using a synth, then it will duplicate highly-loaded nets. > Spectrum tends to produce fanouts of 30 or 40 by default, and in large > synchronous reset nets I've seen maximum net delays of about 12ns on a > Virtex-4. And if you're worried, of course, then you should constrain > the reset to a secondary clock buffer, which will give much better > performance and routing. > > Evan -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18865
With an HDL design there is no GSR signal that you can yank on to initialize simulation unless you put something in your code to get at it. With schematic simulation you have that nice little implied GSR signal you can pulse to reset everything at the beginning of simulation. The synthesis tools won't infer a global reset unless every ff shares the same reset, and rightfully so. The problem is that for HDL simulation, you need some way to get that GSR signal into the ff, it can't just be imagined in. Austin Franklin wrote: > Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote in article > <81197a$12u4$1@noao.edu>... > > Austin Franklin wrote in message <01bf318a$fc7c84d0$207079c0@drt1>... > > > > > >> Don't instantiate the startup block. Just make sure that the reset > > >signal > > >> goes to EVERY SINGLE FLIP-FLOP IN YOUR DESIGN, and your synthesis tool > > >> should infer GSR. If it does not, you should get a message saying > that > > >it > > >> was not inferred, and you'll have to look at the synthesis report to > see > > >> which flops were not included. > > > > > >That sounds tedious, probably un-necessary and may be even not right. > Why > > >not just do it this way: > > > > > >STARTUP_VIRTEX startup_virtex ( > > > .GSR (I_RESET), > > > .GTS (I_TS), > > > .CLK (1'b0) > > > ); > > > > No, neither tedious or unnecessary. And it is right. When I write code > > that's supposed to end up as a flipflop, I always include an async reset > > that uses the GSR. That takes care of the power-on reset. If a flip has > to > > be (re)set any time other than at power-up, I use a synchronous reset. > > It shouldn't be any different to do reset 'correctly' for an HDL design or > a schematic design, so I will ignore any problems that may exist with using > HDLs. This is an architecture issue, not a tool issue. > > How can you say intentionally adding a reset to EVERY flop in the design is > not tedious? Adding code to every instance of a flip flop in the design is > certainly extra work. > > How is it necessary? If the GSR resets every flop, and is on a global > dedicated net that doesn't even take up any resources (that can be used for > something else), and meets timing and operational requirements? > > What are you talking about power on reset? You don't have to do anything > for power on reset, it is inherent in the configuration process. The data > sheet says (and I quote): > > "The default Start-up sequence is that one CCLK cycle after DONE goes High, > the global tri-state signal (GTS) is released. This permits the device > outputs to turn on as necessary. > > One CCLK cycle later, the Global Set/Reset (GSR) and Global Write Enable > (GWE) signals are released. This permits the internal storage elements to > begin changing state in response to the logic and the user clock." > > It also goes on to say it may be paused until DLL lock has been achieved. > > So, given this, I don't understand what or why it is you believe you have > to do special for power-on reset. > > Now, on creating a 'special' net for use as a reset (instead of using the > inherent GSR). The Virtex spec says the delay from GSR to XQ/YQ is under > 10ns. You say you assert your RESET to the part synchronously, so as long > as your clock frequency is not > 100MHz, you will not have any problems > using the dedicated global reset, and therefore, is unnecessary to do it > using non-dedicated resources in this regard. > > The delay from SR to XQ/YQ is 1.1. Using one of the secondary global nets > (you can't use a primary, they only go to clock pins) the delay from the > pad to the SR seems to easily be as high as the dedicated GSR routing, > depending on how far from the input buffer. I only had around 64 flops in > the design, and they were not very far away, and I saw delays as high as > 6+ns, and it burns a LOT of resources. So, with a VERY small design, I am > seeing a delay using a secondary global net of 7.2ns. I had a MAXDELAY and > a MAXSKEW on the RESET net. So, in some instances is MAY be faster, then > again, not, but will only give you any benefit if you are running over > 100MHz. > > If you have an asynchronous reset, then all bets are off with either > method, no matter how low your RESET delay and/or skew is inside your part, > you stand a chance of having some of the chip come out of RESET on a > different clock edge...so you have to design accordingly, which is not too > tough to do, but still does not warrant not using the GSR. > > So, it would also appear that using anything aside from the dedicated GSR > would not give you any benefit (except under very specific conditions), and > therefore, at least for my designs, unnecessary. And given the extra > resources it would use, I would also call it 'wrong'. > > I would appreciate it if you would post some 'facts' as to WHY creating > your own RESET signal, instead of using the dedicated GSR RESET signal, is > somehow beneficial. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18866
I've put simple risc microcontrollers in FPGAs at times when a complex or ill-defined protocol needs to be done in the FPGA. I've got a simple harvard machine that has a register file with separate read/write pointers, an add/subtract accumulator, I/O and conditional branches on 16 conditions that takes up about 70 CLBs in a 4K part, and runs at better than 60 MHz in 4000XL-09 parts. It's kind of a cross between an RCA 1802 (anyone remember those things?) and a PIC. If I were trying to do a TCP stack, I'd probably use a variant of that. Jamie Lokier wrote: > Joel Kolstad writes: > >> I have been told of a small HTTP server on an FPGA. I don't know if > >> they built a processor or not, and I will try to find references. > > > But when do you start calling it a processor (or not...)? > > Well it is a processor of course. It's not a CPU. > > I'd call it a CPU when you make a point of building a CPU and > programming it (or the hardware compiler does that for you). > > > A lot of good sized state machines I've seen start to look an awful > > lot like a microsequencer, and from there it's just a hop, skip, and a > > jump until you decide you're just going to have "this ROM" (that just > > so happens to be a RAM in an FPGA...) that stores microcode and could > > start to have your "hardware TCP/IP implementation" compute Pi or > > crack DES in its spare time... > > None of the network applications I've implemented on FPGAs could be > easily changed to compute Pi or crack DES. And the unfinished TCP/IP > thing did not have a program ROM/RAM. You could add a Pi computer or > DES cracker running in parallel though... > > > If Wade Peterson is around, he can let us know how much of something like a > > Virtex XCV400 his PIC-compatible core takes. I bet it's something under > > 10%. > > I once implemented a stack CPU on an Altera 10K20 in <"300 gates". A > pain to program, but you can make these things very small. > > -- Jamie -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18867
That sounds more like a 'shortcoming' in HDL tools that should have been addressed long ago. Is this 'shortcoming' true for all the major HDL tools (FPGAExpress, Synplicity and Leonardo to name a few) that if you instantiate a STARTUP block (example below), that this logic that is now in your design (if you ran it thru the tools, it would be in the FPGA place and routed output file), does not carry thru to simulation? Ray Andraka <randraka@ids.net> wrote in article <3835596E.6C68AACF@ids.net>... > With an HDL design there is no GSR signal that you can yank on to initialize > simulation unless you put something in your code to get at it. With schematic > simulation you have that nice little implied GSR signal you can pulse to reset > everything at the beginning of simulation. The synthesis tools won't infer a > global reset unless every ff shares the same reset, and rightfully so. The > problem is that for HDL simulation, you need some way to get that GSR signal > into the ff, it can't just be imagined in. > > > > Austin Franklin wrote: > > > Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote in article > > <81197a$12u4$1@noao.edu>... > > > Austin Franklin wrote in message <01bf318a$fc7c84d0$207079c0@drt1>... > > > > > > > >> Don't instantiate the startup block. Just make sure that the reset > > > >signal > > > >> goes to EVERY SINGLE FLIP-FLOP IN YOUR DESIGN, and your synthesis tool > > > >> should infer GSR. If it does not, you should get a message saying > > that > > > >it > > > >> was not inferred, and you'll have to look at the synthesis report to > > see > > > >> which flops were not included. > > > > > > > >That sounds tedious, probably un-necessary and may be even not right. > > Why > > > >not just do it this way: > > > > > > > >STARTUP_VIRTEX startup_virtex ( > > > > .GSR (I_RESET), > > > > .GTS (I_TS), > > > > .CLK (1'b0) > > > > ); > > > > > > No, neither tedious or unnecessary. And it is right. When I write code > > > that's supposed to end up as a flipflop, I always include an async reset > > > that uses the GSR. That takes care of the power-on reset. If a flip has > > to > > > be (re)set any time other than at power-up, I use a synchronous reset. > > > > It shouldn't be any different to do reset 'correctly' for an HDL design or > > a schematic design, so I will ignore any problems that may exist with using > > HDLs. This is an architecture issue, not a tool issue. > > > > How can you say intentionally adding a reset to EVERY flop in the design is > > not tedious? Adding code to every instance of a flip flop in the design is > > certainly extra work. > > > > How is it necessary? If the GSR resets every flop, and is on a global > > dedicated net that doesn't even take up any resources (that can be used for > > something else), and meets timing and operational requirements? > > > > What are you talking about power on reset? You don't have to do anything > > for power on reset, it is inherent in the configuration process. The data > > sheet says (and I quote): > > > > "The default Start-up sequence is that one CCLK cycle after DONE goes High, > > the global tri-state signal (GTS) is released. This permits the device > > outputs to turn on as necessary. > > > > One CCLK cycle later, the Global Set/Reset (GSR) and Global Write Enable > > (GWE) signals are released. This permits the internal storage elements to > > begin changing state in response to the logic and the user clock." > > > > It also goes on to say it may be paused until DLL lock has been achieved. > > > > So, given this, I don't understand what or why it is you believe you have > > to do special for power-on reset. > > > > Now, on creating a 'special' net for use as a reset (instead of using the > > inherent GSR). The Virtex spec says the delay from GSR to XQ/YQ is under > > 10ns. You say you assert your RESET to the part synchronously, so as long > > as your clock frequency is not > 100MHz, you will not have any problems > > using the dedicated global reset, and therefore, is unnecessary to do it > > using non-dedicated resources in this regard. > > > > The delay from SR to XQ/YQ is 1.1. Using one of the secondary global nets > > (you can't use a primary, they only go to clock pins) the delay from the > > pad to the SR seems to easily be as high as the dedicated GSR routing, > > depending on how far from the input buffer. I only had around 64 flops in > > the design, and they were not very far away, and I saw delays as high as > > 6+ns, and it burns a LOT of resources. So, with a VERY small design, I am > > seeing a delay using a secondary global net of 7.2ns. I had a MAXDELAY and > > a MAXSKEW on the RESET net. So, in some instances is MAY be faster, then > > again, not, but will only give you any benefit if you are running over > > 100MHz. > > > > If you have an asynchronous reset, then all bets are off with either > > method, no matter how low your RESET delay and/or skew is inside your part, > > you stand a chance of having some of the chip come out of RESET on a > > different clock edge...so you have to design accordingly, which is not too > > tough to do, but still does not warrant not using the GSR. > > > > So, it would also appear that using anything aside from the dedicated GSR > > would not give you any benefit (except under very specific conditions), and > > therefore, at least for my designs, unnecessary. And given the extra > > resources it would use, I would also call it 'wrong'. > > > > I would appreciate it if you would post some 'facts' as to WHY creating > > your own RESET signal, instead of using the dedicated GSR RESET signal, is > > somehow beneficial. > > > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka > > >Article: 18868
> and in large > synchronous reset nets I've seen maximum net delays of about 12ns on a > Virtex-4. And if you're worried, of course, then you should constrain > the reset to a secondary clock buffer, which will give much better > performance and routing. Not from what I tested. I found the delays thru the secondary buffers to be upwards of 10, if they end up going all over the chip. This seems inane to have to use routing resources for use as a global reset, when there is already a dedicated global reset hard wired in the device, just to accommodate some shortcomings in some tools.Article: 18869
> GSR is indeed too slow for use in higher performance designs. A > better strategy for FPGAs (and I know this makes an ASIC designer's blood > curdle) is to reset only strategic flip-flops in the design, which basically > means you really only need to reset a flip-flop in any logic loops and the > outputs of your chip. Why not just treat GSR like any asynchronous reset? This requires you to add one or more additional RESET states to the start of state machines (or what ever logic you have that this can be effected by), so when flops come out of reset in different clock cycles, there is no ill effect. Then you get ALL the performance you want, since it is now not frequency dependant, except in the fact that you may have to add one or more extra states...Article: 18870
Well, I guess no one has done this??? I've read all the docs I can get my hands on and I think I'm doing everything right. However, the Xilinx doc says that INIT must have a pulldown to ground on it to be able to program the device through the JTAG TAP. The test board we have has a pullup to Vcc on INIT. Is this my problem??? The tools say that the bitstream loads, but the DONE led never goes off and the FPGA does not function. Any help would be appreciated. Tom > I have a development board from VCC that has a Virtex XCV300 onboard. > It can be configured through a flash PROM, a multilink cable, an > xchecker cable and a JTAG port. I am trying to configure it via the > JTAG port so we can learn how this works for our system. >Article: 18871
On Sat, 13 Nov 1999 09:17:00 GMT rbarris@quicksilver.com (Rob Barris) wrote: > > Say for a relatively low end part like a Xilinx XC4005 as seen in the >XESS board, just how many bits is the "bitstream" file that is loaded into >it for configuration? Hundreds, thousands, tens of thousands? > > Sorry if this is a really basic question. I'm exploring tying a >microcontroller to an FPGA, and I'm wondering how much space I need to >worry about dedicating to the config stream. It might change over the >life of the system so a fixed configuration EPROM isn't in the cards. I was just wondering if for the larger parts would worth to compress the bitstream, trading configuration file size by configuration speed, decompressing on the fly. The .bit files compress about 50% with zip or other archiver. 73's de Luis mail: melus@esi.us.es Ampr: eb7gwl.ampr.org http://www.esi.us.es/~melus/ <- Homebrewed Hardware Projects with PCBsArticle: 18872
R&D Technology anounces the availability of it's ARM7TDMI compatible synthesiable Verilog module. For more information look at www.r-and-d.deArticle: 18873
Austin Franklin wrote in message <01bf3240$f071f880$207079c0@drt1>...
>It shouldn't be any different to do reset 'correctly' for an HDL design or
>a schematic design, so I will ignore any problems that may exist with using
>HDLs. This is an architecture issue, not a tool issue.
Well, you can instantiate the GSR if you like, or you can let the tool do it
for you. Me? I prefer to let the tool instantiate GSR. Makes the code a
bit more portable, too, but that's a detail.
>How can you say intentionally adding a reset to EVERY flop in the design is
>not tedious? Adding code to every instance of a flip flop in the design is
>certainly extra work.
Not, not really. Writing:
flop : process (clk, reset)
begin
if reset = '1' then
blah <= '0';
is not too difficult. In fact, emacs conveniently does it for me. It also
has the major advantage of letting the simulation match the reality (i.e.,
at the beginning of time, all flops are reset), and I don't have to deal
with the xilinx simulation models. My test benches assert that reset line
at the beginning of time, and never after that. It's only for power-on
reset.
It might be more difficult (read: time-consuming, tedious) in a schematic to
have to connect the reset net to the async set/reset of every flop; placing
the startup symbol relieves you of that necessity. Then again, you've gotta
hook up the clock signal to every flop.
>How is it necessary? If the GSR resets every flop, and is on a global
>dedicated net that doesn't even take up any resources (that can be used for
>something else), and meets timing and operational requirements?
If you write the code as above, and make sure that all of the flops have an
async reset signal in the sensitivity list, any tool worth a damn at the end
of 1999 should infer GSR, which is what we want. FPGA Express and
Synplicity do. In fact, if you screw up and forget to reset one of the
flops, FPGA Express complains and says that it won't infer GSR. So, of
course it's a PITA to go through the reports and find the flops that you
forgot to reset, but I usually find those sorts of mistakes in pre-synthesis
simulation. There tends to be big Us or Xs and red lines in the wave window
until the flop is explicitly set or cleared.
>What are you talking about power on reset? You don't have to do anything
>for power on reset, it is inherent in the configuration process. The data
>sheet says (and I quote):
Yup, read it many times. I know that the startup sequence after powerup
asserts GSR and resets all of the flipflops that it's connected to.
However, for simulation convenience, it's nice to have a signal the test
bench can assert for power-on reset.
>Now, on creating a 'special' net for use as a reset (instead of using the
>inherent GSR). The Virtex spec says the delay from GSR to XQ/YQ is under
>10ns. You say you assert your RESET to the part synchronously, so as long
>as your clock frequency is not > 100MHz, you will not have any problems
>using the dedicated global reset, and therefore, is unnecessary to do it
>using non-dedicated resources in this regard.
Perhaps I wasn't clear. By "synchronous reset," I meant something like a
counter's synchronous clear signal that is generated by some other logic. I
don't mean that the sync reset is intended to reset the entire chip.
For instance,
count : process (clk, reset) is
begin
if reset = '1' then
counter <= 0; -- reset asserted at beginning of time
elsif rising_edge(clk) then
if clear = '1' then
counter <= 0; -- sync "clear" asserted by other logic
elsif enable = '1' then
counter <= counter + 1
end if;
end if;
end process count;
Clearly, the counter's "clear" signal must meet timing, as does the "enable"
signal, and the counter itself. Perhaps calling the "clear" signal a reset
is a misnomer, even though it's function is to reset a bunch of flipflops.
>If you have an asynchronous reset, then all bets are off with either
>method, no matter how low your RESET delay and/or skew is inside your part,
>you stand a chance of having some of the chip come out of RESET on a
>different clock edge...so you have to design accordingly, which is not too
>tough to do, but still does not warrant not using the GSR.
>
>So, it would also appear that using anything aside from the dedicated GSR
>would not give you any benefit (except under very specific conditions), and
>therefore, at least for my designs, unnecessary. And given the extra
>resources it would use, I would also call it 'wrong'.
Again, my async (GSR) reset is only used at power-up; all other flops are
set or reset synchronously as required by the design.
>I would appreciate it if you would post some 'facts' as to WHY creating
>your own RESET signal, instead of using the dedicated GSR RESET signal, is
>somehow beneficial.
Facts are above, counselor.
--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Creation Science" is oxymoronic.
Article: 18874I have had similar sized '.vo' (verilog) and '.sdo' files with a 93% full 10K200E (low IO count) and was able to successfully do post Place & Route simulations with Modelsim. Simulations do take quite some time to complete if your testbench uses up many cycles. Edwin Grigorian JPL Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:382AA865.C202FD66@algor.co.uk... > > > giuseppe giachella wrote: > > > After placing and routing my design on an Altera Flex 10KA250, Maxplus2 > > created two output files .vho and .sdo in order to start > > a postlayout simulation. These two files have a dimension of 16 MB > > each. It is almost impossible for me to compile such a vhdl and load > > an sdf file so big (I have tried using Modelsim and VSS). > > > > Is there anyone who succeeded in simulating files so big ? > > > > What should I expect if I migrate my design an a APEX or VIRTEX > > (they contain much more gates than a Flex 10KA250) ? > > > > One approach would be to use a perl script to split the postroute netlist > into separate pieces and compile them seprately into a library. > Alternatively if VHDL makes that difficult and you have the co-simulation > version of ModelSim you could output the netlist in the more compact & easy > to split Verilog form. > > For my postlayout Virtex XCV300 simulation I get an 8MB Verilog netlist+8MB > SDF and ModelSim [5.3aPE] handles this with no problems, takes just under 2 > minutes to compile - 450MHz P-II + 512MBytes. > >
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