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
"Ryan Henderson" <hendersr@oit.edu> wrote: > Wow, I hope things really haven't gotten this bad.... > > -Ryan Ryan, Apparently they have and are. The difference between now and the past is that we have this avenue called the Internet to use as a resource. Now we get to see many things that we didn't get to see in the past. I saw a down cycle in the early 1990s that was just as bad as this one, but we didn't get to see how hard up we were back then unless you knew us personally. I post in this and other newsgroups semi-regularly, and because I own a business, my posts draw attention from various engineers, mostly university students, looking for jobs. I can't say that I blame them, but right now I'm looking for business, too! I am very confident, though, that this situation will turn around soon. Everybody, save your nickels, dimes, euros, etc., and let's ride out this roller coaster dip! Simon Ramirez, Consultant Synchronous Design, Inc. Oviedo, FL USAArticle: 40226
On Sat, 2 Mar 2002 16:14:25 +0100, "jerry1111" <jerry1111@wp.pl> wrote: > >Are any GNU C compilers for ARM available? I didn't find them. http://www.armlinux.org/docs/toolchain/ http://www.lart.tudelft.nl/lartware/compile-tools/ Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 40227
Hello all! I am reading the pci specs and found a term 'turnaround cycle'. What is that? Thank you!Article: 40228
The Xilinx VirtexII is the only device that has them that you can buy
today. Altera announced its Stratix line a little more than a week ago,
which also has dedicated multipliers. You'll have to talk to a distributor
to fins out when you can get one.
That said, I am assuming you are talking about audio mixing. If that is the
case, you can get into a smaller, cheaper device by working with bit serial
arithmetic for the mixing. In that case, the multiplier is little more than
an adder. See the multiplier page on my website (when it comes back
up...seems the ball got dropped in transferring the domain name to the new
ISP so it may be a day or so before you can get to the website).
Remco Poelstra wrote:
> Hi,
>
> I want to build a digital mixing console, using an FPGA for the signal
> processing, so I can do it (almost) all in parrallel. I need a lot of
> multipliers for that task. What's the best FPGA to do that? I heard that
> there are FPGA's with build-in multipliers, so I can spend the gates at
> other things, is this true? Which FPGA's have build-in multipliers? Btw,
> I also need a lot of input pins...
>
> Thanks for any advice,
>
> Remco Poelstra
--
--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: 40229Hi, I want to build a digital mixing console, using an FPGA for the signal processing, so I can do it (almost) all in parrallel. I need a lot of multipliers for that task. What's the best FPGA to do that? I heard that there are FPGA's with build-in multipliers, so I can spend the gates at other things, is this true? Which FPGA's have build-in multipliers? Btw, I also need a lot of input pins... Thanks for any advice, Remco PoelstraArticle: 40230
Joey Nelson wrote: > > I'm wondering if it is advisable to embed counting logic in an FSM, say for > a delay. You can embed counting logic in any clocked process. > What I have been doing thus far is having an uber-module with the fsm logic > in one sub-module and the delay in a down-counter sub-module. Then the FSM > loads the counter with the delay count on a Meally output when transiting to > the delay state, it then exits the delay state upon the counter reaching > zero. > I think it would make the design easier to follow if the counting were > simply handled in the FSM with assignments and decrements. I agree. > Is this a reasonable thing to do? If it is easier for you to understand, yes. The most likely person to be modifying this code a year from now is you. Some designers like to think in schematics and code in counter sized modules. Others might see a single process that checks inputs and local (state) variables, and then updates output signals and local variables at every rising clock edge. Most are probably somewhere between these extremes. > How well do synthesis tools handle this? Just fine. Things like: count := count - 1; in a clocked process is bread and butter to most HDL designers. > Can they > still infer the counter? If I have multiple such delays in one FSM, will > the tools recognize the delays are mutually exclusive and only synthesize a > single shared counter? This is the reason you write a testbench and simulate your code. The synthesizer doesn't know what you are thinking, but it will generate a netlist that simulates the same as your code. For an example of inferring a counter and shifter in a single process, see last week's thread "Re: coding style of a FSM" on comp.lang.vhdl -- Mike TreselerArticle: 40231
A turnaround cycle means that an agent driving the PCI bus a clock cycle earlier turns off the driving of the bus, and at the next clock cycle or at later time, another agent can start driving the bus. This turnaround cycle is needed to ensure that contention of driving the bus won't happen. For example, during a read cycle, a turnaround cycle for AD[31:0] occurs a clock cycle after an address phase. For signals like IRDY#, TRDY#, DEVSEL#, and STOP#, a turnaround cycle occurs during an address phase when a Fast Back-to-Back transfer is happening, and when a Fast Back-to-Back transfer is not happening, a turnaround cycle occurs during an idle cycle (An idle cycle is, FRAME# = 'H' and IRDY# = 'H'.). However, for other signals like AD[31:0], C/BE#[3:0], and FRAME#, a turnaround cycle happens during an idle cycle. PAR's turnaround cycle occurs one cycle later than the turnaround cycle of AD[31:0] and C/BE#[3:0]. Kevin Brace (Don't respond to me directly, respond within the newsgroup.) Vladimir Ralev wrote: > > Hello all! > > I am reading the pci specs and found a term 'turnaround cycle'. What is that? > > Thank you!Article: 40232
"Victor Schutte" <victors@mweb.co.za> writes: > Jerry, look at this in a different way. NIOS provides you with a complete IP > CPU solution. You can migrate this design between different Altera FPGAs, Can you run Linux on the NIOS? Does it have a MMU? What would be the cost of migrating to an ASIC in terms of license fees? Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 40233
Remco Poelstra wrote: > Which FPGA's have build-in multipliers? Xilinx virtex2 is in stock. Altera stratix was just announced. "The first device, the EP1S25, will be sampling in the second quarter with volume pricing starting at $125 in 2003." -- Mike TreselerArticle: 40234
As an Altera devotee, I would strongly suggest you take a look at Xilinx parts for now. Right software,, right silicon, and right support from some expert 'volunteers' here and elsewhere. People like Ray Andraka and Peter Alfke make a huge difference. Paul "Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message news:3C814D22.C0440767@flukenetworks.com... > Remco Poelstra wrote: > > > Which FPGA's have build-in multipliers? > > Xilinx virtex2 is in stock. > > Altera stratix was just announced. > "The first device, the EP1S25, will be sampling > in the second quarter with volume > pricing starting at $125 in 2003." > > -- Mike TreselerArticle: 40235
Petter Gustad <newsmailcomp1@gustad.com> wrote in message news:87r8n2slz0.fsf@filestore.home.gustad.com... > Can you run Linux on the NIOS? Does it have a MMU? What would be the > cost of migrating to an ASIC in terms of license fees? > > Petter Petter, Micronix has a uC Linux port for Nios. Like all Linux versions, I suppose the source code is freely available from Micronix somewhere, but you can buy a "supported" version though Altera's Linux Development Kit. The kit is an add-on to the Nios dev. board and includes the Linux software, an SODIMM card with a bunch of SRAM and Flash on board, an attachement which adds a real-time clock and an IDE/Compact Flash interface, and a 10baseT ethernet MAC/PHY connector. It also comes with a web-server application as an example design. uC Linux is a version of Linux that was made specifically for embedded systems (read: no MMU required). As far as migrating to an ASIC, Altera has said that they will license the core for an ASIC "at an additional cost". I honestly have no idea what sort of cost this would be (contact an Altera salescritter for this sort of info). As long as I'm posting, I'll also respond to Jerry1111's last post about the difference between the Excalibur ARM development Kit and the Excalibur Nios development kit: Think of the Excalibur ARM development kit as an evaluation board with some support software included (The ARM Developers Suite (Lite), reference designs, utilities, etc). The Nios development kit is a package of Intellectual Property for the Nios CPU and a bunch of peripherals (UART, timers, SPI, DMA, I/O, etc) with an included evaluation board, a license for tools, a programming cable, and a bunch of documentation. If you were to create a system with an Excalibur ARM device containing several Nios processors in the programmable section, you'd have to get the Nios kit (for the IP license), but you wouldn't need the Excalbur ARM development kit unless you didn't want to design your own board to hold the device. -Pete-Article: 40236
I seem to be stumped. Using the Xilinx WebPack to do some XC9500 work. Everything works great including the actual hardware. When I do a behaviorial simulation I put a little verilog block in that pulses PRLD, GTS, GR, and GSR -- I know I don't need all of them, but I just use on block for every case. That works fine. However, when I try to simulate post fit without the simulation block (which won't work in synthesis) I can't get the simulation to work. I manually set the PRLD and other lines. It will look like it works until suddenly a T flip flop should flip and instead goes to x and stays there. Again, with the little sim block it works great. And it works great in the real hardware. Any tips? Thanks in advance.Article: 40237
Dear All, I am using Xilinx Spartan II only in my projects. I have ModelSIm PE to be my simlulator. As I known, Xilinx release a new simulator, MXE 5.5. Comparing those two proces, MXE seems much cheaper. If I am going to use Spartan II only, is it better to purchase MXE ? Please advise, thanks. KennyArticle: 40238
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:<a5rhml$5e2$1@newsreader.mailgate.org>... > A turnaround cycle means that an agent driving the PCI bus a clock cycle > earlier turns off the driving of the bus, and at the next clock cycle or > at later time, another agent can start driving the bus. > This turnaround cycle is needed to ensure that contention of driving the > bus won't happen. > For example, during a read cycle, a turnaround cycle for AD[31:0] occurs > a clock cycle after an address phase. There is still something unclear: If I sample the data on AD[31:0] during a turnaround cycle after the address phase(the example u mentioned about), what would i get? The last state? ThanksArticle: 40239
Hi Ray, I have seen these tips written by you many times in this group. I have them always as a guide but I want to see if I understand them right. Please correct me where I am wrong: 1) The need for additional registers in DATA_IN and ADDR signals. In BRAMs the EN and WE signals have long set-up times thats why we need to register the data_in and addr of the BRAM, in this way the addr and data_in signals have a clock period delay.As EN,WE reach the BRAM 1 clock period earlier (at 155MHz clock speed that means about 6 ns) the setup-time for these signals is not violated resulting BRAM to be in the operation mode we wish (read or write) the moment addr and data_in arrive. 2) The need for floorplanning Xilinx software tool maybe has put the additional registers far from the BRAMs, if this is the case we must manual place them near the BRAM to decrease the propagation delay of the signals. 3) Tying the WE,EN inputs and contol access through the address when working at high speeds. Do you mean to keep WE,EN high all the time and when we wish not to use the BRAMs to write dummy data in some (or just one) specified addresses (or address) reserved for this reason? Also I have another one question about BRAMs, Xilinx says that BRAMs' DATA OUT are already registered. In Xilinx Floorplanner I believe this register is "inside" the BLKRAM box so no manual floorplanning for the output is needed. You need to manual floorplan (in the same way you do for the inputs) only if you choose to add an additional output register, correct? I really appreciate your help. Best Regards, Harris "Ray Andraka" <ray@andraka.com> wrote in message news:3C7FD73D.F6A3109A@andraka.com... > VirtexE BRAMs can be written at 155MHz in any speed grade. To do so, you will > likely have to put registers near to and with no logic between them and the > BRAMs. Watch the loading too, routing to more than 1 BRAM for each register may > cause you some heartburn. At higher speeds, you probably should also consider > tying the WE, and ENA inputs active and controlling your access through the > address registers instead. You'll also need to floorplan the registers to make > sure they are located physically close to the BRAMs. > > "H.L" wrote: > > > Hi Peter, thanks for your reply > > I was confident of this method's effectiveness but now I am worried :)) . I > > have already done a timing analysis in the paper and also the simulation > > waveforms seem promising. > > I didnt understand what do you mean when telling me that one of my words > > arrives early and the other one late. The transmitter sends to my FPGA an > > external clock (thats the 155MHz clock), a valid signal (1 bit indicating > > the transmission time period) and of course the 16-bit words that I have to > > store. Every clock period (~6 ns) I have available in my ports one 16-bit > > word, I register two sequential words from the in port to a 32-bit register > > (31->16 the first incoming word, 15->0 the second one). Then , in another > > 32-bit register I register (2 nd time) the 32-bit word I just "made" which > > are the BRAM data_in. All the above operations are in a process that has in > > its sensitivity list the 155 clock. I write to the BRAM at 77MHz using the > > incoming clock divide by 2 using a DLL. BRAM input signals are assigned in > > the falling edge of the 77MHz clock so as to be before the rising edge (of > > the same clock) where the BRAM samples them. The write operations are in > > another process with the slow clock in its sensitivity list. > > The timing waveforms of the simulation are the same with the timing analysis > > in paper but does this is a valid hardware design technique? > > Thanks for your time and help! > > > > Best Regards, > > Harris > > > > p.s: thats a small part of my design. I use DLL because other parts need > > them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155 MHz and I > > got many timing errors (floorplanning managed to reduce them but still lot > > of work to be done) > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message > > news:3C7E621F.1E77A244@xilinx.com... > > > I suggest you grab pencil and paper and do a clock-by-clock timing > > analysis. You > > > will find that your clock-speed reduction buys you nothing, unless you > > also > > > double-buffer the data. > > > One of your words arrives nice and early, the other one late. However you > > clock > > > the BRAM, one of the two words has the same old short set-up time... > > > Double-buffering would help. But Ray has mentioned some neat tricks to > > avoid the > > > long set-up time of the control inputs. > > > > > > I will get back with more constructive notes. "Gotta run" > > > > > > Peter Alfke > > > =================== > > > "H.L" wrote: > > > > > > > Hello all, > > > > > > > > I have a module that accepts 16 bit words at 155MHz and I want to store > > then > > > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA) to > > divide by > > > > 2 the 155MHz clock as this frequency seems to be pretty high to write in > > the > > > > BRAM. So far I think 2 processes are enough to do my job, one operating > > @ > > > > 155MHz to accept the 16-bit data and store them in a 32-bit register and > > the > > > > another one @ 75MHz to write the content of the 32-bit register in the > > BRAM. > > > > I am thinking to assign the BRAM's signals > > (ENABLE,WRITE,ADDRESS,DATA_IN) in > > > > the falling edge of the 75MHz clock, the main reason for this is the > > setup > > > > time of the BRAMs signals (in this way the address,data are 6 ns before > > next > > > > rising edge of the clock where BRAM samples its inputs). My question now > > :) > > > > , if one process uses the falling edge of one clock does this causes > > > > problems to other processes in the design , e.g to processes that use a > > > > different clock or to processes using the rising edge of the same > > clock? > > > > > > > > Best Regards, > > > > Harris. > > > > > -- > --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: 40240
Hi Peter, I didnt know that this thing I did is called "double-buffering" so thank you :-) I use a Virtex-E FPGA for my design. I dont know the thing that you mentioned about reading at different width, I will take a look at Virtex-II BRAM datasheet to learn more. Best Regards, Harris "Peter Alfke" <peter.alfke@xilinx.com> wrote in message news:3C7FE5D2.867309EA@xilinx.com... > O.K. as I wrote: "double-buffering would help", and that's what you are doing. > Sorry for my insulting assumptions ;-) > Ray already mentioned that 155 MHz would be o.k. if you floorplan accorcingly. > Are you using Virtex-II? You probably know that you can read out data at a > different width, if that helps you. In your case, you can read out 16 bits wide, > although you wrote 32 bits wide. Provided the speed is right. > > Greetings > Peter Alfke, Xilinx Applications > > > "H.L" wrote: > > > Hi Peter, thanks for your reply > > I was confident of this method's effectiveness but now I am worried :)) . I > > have already done a timing analysis in the paper and also the simulation > > waveforms seem promising. > > I didnt understand what do you mean when telling me that one of my words > > arrives early and the other one late. The transmitter sends to my FPGA an > > external clock (thats the 155MHz clock), a valid signal (1 bit indicating > > the transmission time period) and of course the 16-bit words that I have to > > store. Every clock period (~6 ns) I have available in my ports one 16-bit > > word, I register two sequential words from the in port to a 32-bit register > > (31->16 the first incoming word, 15->0 the second one). Then , in another > > 32-bit register I register (2 nd time) the 32-bit word I just "made" which > > are the BRAM data_in. All the above operations are in a process that has in > > its sensitivity list the 155 clock. I write to the BRAM at 77MHz using the > > incoming clock divide by 2 using a DLL. BRAM input signals are assigned in > > the falling edge of the 77MHz clock so as to be before the rising edge (of > > the same clock) where the BRAM samples them. The write operations are in > > another process with the slow clock in its sensitivity list. > > The timing waveforms of the simulation are the same with the timing analysis > > in paper but does this is a valid hardware design technique? > > Thanks for your time and help! > > > > Best Regards, > > Harris > > > > p.s: thats a small part of my design. I use DLL because other parts need > > them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155 MHz and I > > got many timing errors (floorplanning managed to reduce them but still lot > > of work to be done) > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message > > news:3C7E621F.1E77A244@xilinx.com... > > > I suggest you grab pencil and paper and do a clock-by-clock timing > > analysis. You > > > will find that your clock-speed reduction buys you nothing, unless you > > also > > > double-buffer the data. > > > One of your words arrives nice and early, the other one late. However you > > clock > > > the BRAM, one of the two words has the same old short set-up time... > > > Double-buffering would help. But Ray has mentioned some neat tricks to > > avoid the > > > long set-up time of the control inputs. > > > > > > I will get back with more constructive notes. "Gotta run" > > > > > > Peter Alfke > > > =================== > > > "H.L" wrote: > > > > > > > Hello all, > > > > > > > > I have a module that accepts 16 bit words at 155MHz and I want to store > > then > > > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA) to > > divide by > > > > 2 the 155MHz clock as this frequency seems to be pretty high to write in > > the > > > > BRAM. So far I think 2 processes are enough to do my job, one operating > > @ > > > > 155MHz to accept the 16-bit data and store them in a 32-bit register and > > the > > > > another one @ 75MHz to write the content of the 32-bit register in the > > BRAM. > > > > I am thinking to assign the BRAM's signals > > (ENABLE,WRITE,ADDRESS,DATA_IN) in > > > > the falling edge of the 75MHz clock, the main reason for this is the > > setup > > > > time of the BRAMs signals (in this way the address,data are 6 ns before > > next > > > > rising edge of the clock where BRAM samples its inputs). My question now > > :) > > > > , if one process uses the falling edge of one clock does this causes > > > > problems to other processes in the design , e.g to processes that use a > > > > different clock or to processes using the rising edge of the same > > clock? > > > > > > > > Best Regards, > > > > Harris. > > > >Article: 40241
> Micronix has a uC Linux port for Nios. Like all Linux versions, I suppose > the source code is freely available from Micronix somewhere, but you can buy Source is not freely available (you got src when you buy uCLinux). At least I didn't find it in microtronix website. > uC Linux is a version of Linux that was made specifically for embedded > systems (read: no MMU required). I'm thinking about stability of this version. If one process goes wrong it can crash all processes (no MMU => no SIGSEGV => we don't even know about destroying other processes' data/program space). > Think of the Excalibur ARM development kit as an evaluation board with some So, if I have my own board with Atera's Arm-filled fpga, the only thing I need is description file of FPGA which tells Quartus where are ARM's pins inside structure? And then I can use 3rd party software tools? And question about embedded linux. Which one to choose? For Nios (costs money) or some free versioins for ARM? Have someone used them? jerryArticle: 40242
Vladimir Ralev wrote: > Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:<a5rhml$5e2$1@newsreader.mailgate.org>... > > A turnaround cycle means that an agent driving the PCI bus a clock cycle > > earlier turns off the driving of the bus, and at the next clock cycle or > > at later time, another agent can start driving the bus. > > This turnaround cycle is needed to ensure that contention of driving the > > bus won't happen. > > For example, during a read cycle, a turnaround cycle for AD[31:0] occurs > > a clock cycle after an address phase. > > There is still something unclear: > If I sample the data on AD[31:0] during a turnaround cycle after the > address phase(the example u mentioned about), what would i get? The > last state? > > Thanks Its possible to argue that a CMOS bus would hold the last value driven onto it for at least one 33MHz clock however its equally possible that the clock edge used to float the drivers also changes the value in the initiator's output data registers so you'll get a race. Therefore ... ... You must assume you'll get the second most infamous digital object of them all - the great, system eating, "UNDEFINED". As the Bhuddists say: ``Pass over it, but build no house on it'' :-). The most infamous is of course metastability but one could argue that its an analogue phenomenon.Article: 40243
Al Williams wrote: > I seem to be stumped. > > Using the Xilinx WebPack to do some XC9500 work. Everything works > great including the actual hardware. When I do a behaviorial > simulation I put a little verilog block in that pulses PRLD, GTS, GR, > and GSR -- I know I don't need all of them, but I just use on block > for every case. That works fine. > > However, when I try to simulate post fit without the simulation block > (which won't work in synthesis) I can't get the simulation to work. I > manually set the PRLD and other lines. It will look like it works > until suddenly a T flip flop should flip and instead goes to x and > stays there. Again, with the little sim block it works great. And it > works great in the real hardware. > > Any tips? > > Thanks in advance. If you are using the post-fit net list then you have moved into the realm of timing simulation and so you may be getting setup/hold violations on your T-FF. The simprim models used for this simulation will set the output to `X' when such a violation occurs. This is esp. likely if the FF is sampling an asynchronous input. You could try either: o Slowing down the clock, or o If you're using the ModelSim starter edition that comes with WebPACK try setting +no_notifier on the vsim command line or even +notimingchecks. Make sure, though, that +no_tchk_msg is *not* set so that you can see any timing violations even if they don't set the output to `X'.Article: 40244
Hi, Finally I managed to finish my final year project concern FIR digital filter using VHDL. I want to thank you to all the experts here, especially Ray,Cohen and others. Thank you for the advices. This is a very good group and I recommend to anyone who needs advice in VHDL and FPGAs. Regards, DanielArticle: 40245
"H.L" wrote > I use a Virtex-E FPGA for my design. I dont know the thing that you > mentioned about reading at different width, I will take a look at Virtex-II > BRAM datasheet to learn more. All Xilinx BlockRAMs are dual-ported. Each port has its own address data, WE, EN, and clock. The only thing the two ports have in common is the storage array. But each port's "aspect ratio" can also be independently configured. So one port can have many parallel data bits and fewer address bits, while the other port has narrower data and more adresses. There are no constraints. That sometimes eliminates the need for a P/S or S/P converter. Regarding your question about an internal output register: There is no extra output register, but as the data sheet says: "The state of the (data ) outputs will not change until the port excutes another read or write operation". If you feel like it, you can consider it an output register, but it really is just looking at the internal data array, using its latched adress. Peter Alfke, Xilinx ApplicationsArticle: 40246
Hi Paul, When getting into new things in the past, I have found 'Wiki's to be very usefull, -when- they are well maintained. (the father of them all is http://c2.com/cgi/wiki) Being new to programmable logic, I have found both this newsgroup and the FAQ tremendous resources (with a big thanks to all who contribute.) I have been tempted to try setting up a wiki with a slant towards DSP-FPGA design, but it's all a matter of time and knowledge... I would be intrested in helping with such a project, as it would be interesting to see how such a system might complement the ng/faq, but I guess it's really a question of weather others would be interested (.... :-) It'd be nice to find somewhere where the more 'far out' FPGA bassed voodoo is discussed (like projects where designs are bred 'genetically' resulting in very odd designs that get the job done very oddly. Can't find the references at the moment... - admited such things can't do much at the moment, and probably won't mean much comercially for some time, bit I find that sort of thing fascinating) Anyway, just my two pence. Chris Saunter Paul (nospam@nospamplease.com) wrote: : Having come back to logic design after a 5 year break, I had a bit of a : culture-shock with the myriad of different tools and their inherent : strengths and weaknesses. : I'm hoping to help make it a bit easier for others and expand my current : limited understanding by creating a set of forums for discussion. : My aim in creating the forums was: : 1) Provide a forum for discussion of various programmable logic tools and : how best to use them. : 2) Provide a place to store tips and techniques used by programmable logic : designers. : 3) Complement the discussions on the main programmable logic newsgroups and : perhaps go into more specific detail and provide more tutorial information : to supplement the newsgroup information. : 4) Provide an edited summary of valuable discussions on the newsgroups. : At present I'd appreciate any comment and assistance in starting up the : process. : http://pub64.ezboard.com/bfpgatipsandtricks : Because the forums are new I've focussed on Altera-based tools, but over the : coming weeks if there is sufficient interest I'll attempt to extend them to : other device toolsets. : I should point out that there is little useful content on the forums as yet, : which is where your assistance would be invaluable. : You will need to register a user name, email and some details to post : (viewing doesn't require this). How accurately you want to do this is : entirely up to you. : If you need to contact me, try pauljnospambaxter@hotnospammail.com without : the nospam bits. : Feedback appreciated.Article: 40247
"H.L" wrote:
> Hi Ray,
> I have seen these tips written by you many times in this group. I have them
> always as a guide but I want to see if I understand them right. Please
> correct me where I am wrong:
>
> 1) The need for additional registers in DATA_IN and ADDR signals.
> In BRAMs the EN and WE signals have long set-up times thats why we need to
> register the data_in and addr of the BRAM, in this way the addr and data_in
> signals have a clock period delay.As EN,WE reach the BRAM 1 clock period
> earlier (at 155MHz clock speed that means about 6 ns) the setup-time for
> these signals is not violated resulting BRAM to be in the operation mode we
> wish (read or write) the moment addr and data_in arrive.
If you look at the data sheet, there are fairly long set-up times on all the
BRAM inputs. Routing to the BRAMs also adds to the delay, as does any
combinatorial logic on these inputs. The idea of putting registers on the
inputs (which includes the EN and WE inputs) is to minimize the amount of delay
added externally to these signals. Your understanding is a bit incorrect, as
what you are suggesting is delaying signals to allow a long combinatorial
delay. That is dangerous, because there is no guarantee on the minimum delay.
Instead, what I am suggesting is to remove as much of the delay as possible
between the registers driving the BRAM inputs and the BRAM inputs, which meahs
avoiding combinatorial logic on these paths, minimizing the fanout of these
signals, and physically locating the registers close to the BRAMs.
>
> 2) The need for floorplanning
> Xilinx software tool maybe has put the additional registers far from the
> BRAMs, if this is the case we must manual place them near the BRAM to
> decrease the propagation delay of the signals.
That is correct. Routing in FPGAs is not just wire, it also consists of
switches which add to the propagation delay of signals on the connections
between logic. Manually placing the registers near the BRAM helps to minimize
the added delay.
>
> 3) Tying the WE,EN inputs and contol access through the address when working
> at high speeds.
> Do you mean to keep WE,EN high all the time and when we wish not to use the
> BRAMs to write dummy data in some (or just one) specified addresses (or
> address) reserved for this reason?
That is correct. The set up times for EN and WE are nearly twice the set-up
times for address and data, so if we can eliminate these from the equation we
can run at a higher clock rate. They can be eliminated by always writing, but
directing the writes of invalid data to locations where it does not affect the
operation of the design. In the case of FIFOs, you can just park the write
address until you have a valid write, since you are presumably not reading that
data until it is valid.
>
>
> Also I have another one question about BRAMs, Xilinx says that BRAMs' DATA
> OUT are already registered. In Xilinx Floorplanner I believe this register
> is "inside" the BLKRAM box so no manual floorplanning for the output is
> needed. You need to manual floorplan (in the same way you do for the inputs)
> only if you choose to add an additional output register, correct?
That is correct, the BRAM acts as though it is registered, although I believe
the actual implementation has the register on the address, not on the memroy
outputs. In any event, the clock to out time is long compared to that of the
CLB flip-flops. The system clock rate can be increased by putting an additional
register on the BRAM data outputs and placing that register physically close to
the BRAM (that register should have no combinatorial logic in front of it).
>
>
> I really appreciate your help.
>
> Best Regards,
> Harris
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3C7FD73D.F6A3109A@andraka.com...
> > VirtexE BRAMs can be written at 155MHz in any speed grade. To do so, you
> will
> > likely have to put registers near to and with no logic between them and
> the
> > BRAMs. Watch the loading too, routing to more than 1 BRAM for each
> register may
> > cause you some heartburn. At higher speeds, you probably should also
> consider
> > tying the WE, and ENA inputs active and controlling your access through
> the
> > address registers instead. You'll also need to floorplan the registers to
> make
> > sure they are located physically close to the BRAMs.
> >
> > "H.L" wrote:
> >
> > > Hi Peter, thanks for your reply
> > > I was confident of this method's effectiveness but now I am worried :))
> . I
> > > have already done a timing analysis in the paper and also the simulation
> > > waveforms seem promising.
> > > I didnt understand what do you mean when telling me that one of my words
> > > arrives early and the other one late. The transmitter sends to my FPGA
> an
> > > external clock (thats the 155MHz clock), a valid signal (1 bit
> indicating
> > > the transmission time period) and of course the 16-bit words that I have
> to
> > > store. Every clock period (~6 ns) I have available in my ports one
> 16-bit
> > > word, I register two sequential words from the in port to a 32-bit
> register
> > > (31->16 the first incoming word, 15->0 the second one). Then , in
> another
> > > 32-bit register I register (2 nd time) the 32-bit word I just "made"
> which
> > > are the BRAM data_in. All the above operations are in a process that has
> in
> > > its sensitivity list the 155 clock. I write to the BRAM at 77MHz using
> the
> > > incoming clock divide by 2 using a DLL. BRAM input signals are assigned
> in
> > > the falling edge of the 77MHz clock so as to be before the rising edge
> (of
> > > the same clock) where the BRAM samples them. The write operations are in
> > > another process with the slow clock in its sensitivity list.
> > > The timing waveforms of the simulation are the same with the timing
> analysis
> > > in paper but does this is a valid hardware design technique?
> > > Thanks for your time and help!
> > >
> > > Best Regards,
> > > Harris
> > >
> > > p.s: thats a small part of my design. I use DLL because other parts need
> > > them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155 MHz
> and I
> > > got many timing errors (floorplanning managed to reduce them but still
> lot
> > > of work to be done)
> > >
> > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> > > news:3C7E621F.1E77A244@xilinx.com...
> > > > I suggest you grab pencil and paper and do a clock-by-clock timing
> > > analysis. You
> > > > will find that your clock-speed reduction buys you nothing, unless you
> > > also
> > > > double-buffer the data.
> > > > One of your words arrives nice and early, the other one late. However
> you
> > > clock
> > > > the BRAM, one of the two words has the same old short set-up time...
> > > > Double-buffering would help. But Ray has mentioned some neat tricks to
> > > avoid the
> > > > long set-up time of the control inputs.
> > > >
> > > > I will get back with more constructive notes. "Gotta run"
> > > >
> > > > Peter Alfke
> > > > ===================
> > > > "H.L" wrote:
> > > >
> > > > > Hello all,
> > > > >
> > > > > I have a module that accepts 16 bit words at 155MHz and I want to
> store
> > > then
> > > > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA) to
> > > divide by
> > > > > 2 the 155MHz clock as this frequency seems to be pretty high to
> write in
> > > the
> > > > > BRAM. So far I think 2 processes are enough to do my job, one
> operating
> > > @
> > > > > 155MHz to accept the 16-bit data and store them in a 32-bit register
> and
> > > the
> > > > > another one @ 75MHz to write the content of the 32-bit register in
> the
> > > BRAM.
> > > > > I am thinking to assign the BRAM's signals
> > > (ENABLE,WRITE,ADDRESS,DATA_IN) in
> > > > > the falling edge of the 75MHz clock, the main reason for this is the
> > > setup
> > > > > time of the BRAMs signals (in this way the address,data are 6 ns
> before
> > > next
> > > > > rising edge of the clock where BRAM samples its inputs). My question
> now
> > > :)
> > > > > , if one process uses the falling edge of one clock does this causes
> > > > > problems to other processes in the design , e.g to processes that
> use a
> > > > > different clock or to processes using the rising edge of the same
> > > clock?
> > > > >
> > > > > Best Regards,
> > > > > Harris.
> > > >
> >
> > --
> > --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: 40248Joey Nelson wrote: > > I'm wondering if it is advisable to embed counting logic in an FSM, say for > a delay. > > What I have been doing thus far is having an uber-module with the fsm logic > in one sub-module and the delay in a down-counter sub-module. Then the FSM > loads the counter with the delay count on a Meally output when transiting to > the delay state, it then exits the delay state upon the counter reaching > zero. > > I think it would make the design easier to follow if the counting were > simply handled in the FSM with assignments and decrements. Is this a > reasonable thing to do? How well do synthesis tools handle this? Can they > still infer the counter? If I have multiple such delays in one FSM, will > the tools recognize the delays are mutually exclusive and only synthesize a > single shared counter? > > If any one has any insight it would be much appreciated. > > Joey I don't think it will make much difference either way, except for fast designs where you need to control each state variable and output to meet timing. Then it will likely be easier to control your result if the counter is separate. I doubt that the synthesizer can figure out that several counters can be optimized into one, but it won't see your delay states as a counter. They will just be more states in your FSM and the entire machine will be optimized together. As long as you don't try to use one hot encoding, it will do a reasonable job of it. The only question is, will the added counter states make the FSM too complex to run at your required speed? Keeping the counter separate will allow you to make the FSM simpler and easier to meet timing. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 40249
Magnus Homann wrote: > > Rick, > > http://www.xilinx.com/ise/marketing/index.htm > > (Just ignore that it says 'marketing' in the link...) > > Homann > -- > Magnus Homann, M.Sc. CS & E > d0asta@dtek.chalmers.se It can be ignored, but you will notice that there is no real information on these pages. But it is a start. Too bad that I am using Spartan IIE and this is only available for VirtexII and E. We will see if they come out with updates for Spartan lines. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
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