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
"Rob" <BertyBooster@googlemail.com> wrote in message news:557bc806-ddb8-4890-b41f-5b6335e771a0@e67g2000hsc.googlegroups.com... > > Since each IO will consume power to change state (due > to driving external capacitance) > Hi Rob, Not just external capacitance, but internal also. FPGAs tend to support a lot of output standards. For example, some Xilinx FPGAs claim a drive strength of 24 mA. The penalty paid for this flexibility is that it requires fairly hefty FETs which have a fairly large drain-source capacitance (Cds), leading to a Cpin of up to 10pF. This Cds needs charging by the output when it switches. The output drive standard is adjustable, as far as I can make out, by having several FETs in parallel, and switching on enough FETs to achieve the desired drive. Of course, all the FETs not being used in the lower drive strengths still present their Cds, which needs charging. Naturally, at lower drive strengths this charging current is lower and is so spread out over a longer time period, all of which gives the PDS a better chance of keeping the rails up, but the energy loss in the internal parasitic capacitance is the same no matter what drive strength is used. I point this out because this parasitic FPGA pin capacitance is often the dominant loading on a FPGA output pin, cf a memory device that may have a Cpin on an address input of only 2.5pF. HTH., Syms.Article: 126901
On Dec 5, 12:13 pm, guy <MADO...@gmail.com> wrote: > hello > when i look at the timing report of my fpga > i see that the why do i see negative clock hold time > of my input pins is NEGATIVE > Thold= -5ns > > i dont understand why > > thanks for the help Thold is the amount of time after the clock that the input must remain stable. Negative hold time means that the input does not need to be stable for some period of time prior to the clock. If the Thold= -5ns that you're looking at is for the fast timing model, it means that you could theoretically switch the input 5 ns prior to the clock and it would still work. If the Thold is in a report from the slow timing model, then the number is meaningless. KJArticle: 126902
rickman wrote:
> I agree. This is the sort of thing that is very hard to find in a
> design once it gets past your simulation and fails on the real chip.
> I suppose it would fail in a post route simulation, no?
Yes. Even though post-route sims are slow,
and don't cover timing as well as STA, they almost
always find synthesis errors.
This is an important check-off item before
releasing an fpga image for system verification.
I have not personally run into a synthesis error
in nine years, because I tend to use the
same style on the same tools, but this example shows,
it is possible to hit one.
I like to collect corner cases like this one
and KJ's list and to evaluate new tools.
Thanks for the soapbox ;)
-- Mike Treseler
Article: 126903On Dec 5, 12:58 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > rickman wrote: > > The only trouble is that this is not at all equivalent to the code I > > wrote. This code is describing two registers with two separate inputs > > and two separate outputs that are then XORed together. How is this > > like a register that is clocked on both edges of the clock? > > Like this?http://home.comcast.net/~mike_treseler/double_edge.pdfhttp://home.comcast.net/~mike_treseler/double_edge.vhd > > -- Mike Treseler I didn't see the xors in the register inputs. This is a nice little trick. I will remember it.Article: 126904
On Dec 5, 10:45 am, MikeShepherd...@btinternet.com wrote: > I have a simple design (about 300 logic elements / 150 registers) > written in Verilog. It's highly self-contained (only about ten > signals on the interface). > > (For the curious, it performs a function for analogue video). > > It's now proposed to incorporate this in a design which is otherwise > VHDL (and over which I shall have no control). > > Obviously, the Verilog could be converted, but this would be > significant work (and I no have no experience at present of VHDL). For > this reason (and particularly since the interface is simple), I'd like > to keep my part of the design in Verilog. > > Is mixed-language design well-supported? If so, does anyone have > general advice or words of caution? > > Mike Mike, You did not tell us what tools you are using, here or in that other thread! We use a mixture of VHDL and Verilog with almost no problems. Our tool set of interest is EDK/ISE and ModelSim. We have both cases of VHDL instantiating Verilog, and Verilog instantiating VHDL. The one problem that we have come across is in passing 32 bit generics from VHDL to Verilog when the MSB is set. In this case it is when passing bus address assignments. I don't remember the exact details other than it being related to signed vs unsigned, but ISE required us to perform one conversion on the generics before passing them, and ModelSim required something else. Other than that, it has just worked. Regards, John McCaskill www.fastertechnology.comArticle: 126905
Alas the design is from somebody else so I don't have the option to re- write it. Thanks for the insight. I asked this question because it seems that for 1 net, XST is routing the signal from a DCM on the right side to a BUFGMUX on the bottom side. This is introducing additional delays that I would like to remove. I get the following issue during PAR which i am trying to resolve: WARNING:Place:619 - This design either uses more than 8 clock buffers or uses more than 4 DCMs or has clock buffers locked to side-BUFG sites or has DCMs locked to side-DCM sites. The side-DCMs can drive only the BUFGs on the same side. Since side-BUFGs can drive only their half of the device and also exclude a global-BUFG from entering a clock region, it is necessary to partition the clock logic being driven by these clocks into different clock regions. It may be possible through Floorplanning all or just part of the logic being driven by the global clocks to achieve a legal placement for this design......... ...... ........................ WARNING:Place:620 - A DCM / BUFGCTRL clock component pair have been found that are not placed at an optimal DCM / BUFGCTRL site pair. The DCM component <Clock_Tree/SDRAM_CLK_GEN/ DCM_SP_INST> is locked to site <DCM_X3Y1> and the corresponding BUFGCTRL component <Clock_Tree/SDRAM_CLK_GEN/ CLK0_BUFG_INST> is locked to site <BUFGMUX_X2Y1>. This will not allow the usage of the fast path between the DCM and the Clock buffer. You may want to analyze why this problem exists and correct it. This is not an error so processing will continue. Phase 4.2 (Checksum:99f58b) REAL time: 23 secs Phase 5.30 ERROR:Place:848 - Automatic clock placement failed. Please attempt to analyze the global clocking required for this design and either lock the clock placement or area locate the logic driven by the clocks so that that the clocks may be placed in such a way that all logic driven by them may be routed. The main restriction on clock placement is that only one clock output signal for any competing Global / Side pair of clocks may enter any region. For further information see the "Quadrant Clock Routing" section in the Spartan3e Family Datasheet. It's a pain i the butt :) Thanks for the help AmishArticle: 126906
Many thanks for that. At least I know it isn't seen as a minefield. As yet, I don't know what tools are used on the VHDL side. MikeArticle: 126907
>> Lattice: Despite the abysmal experience of a visit by the UK/Ireland >> Sales manager... >I recently started working for a Lattice distributor in Ireland / UK >and I am fairly shocked by your experience. : : >Eoin Dowling >FMG Electronics I should probably make it clear that our poor experience was not with FMG Electronics. MikeArticle: 126908
ghelbig@lycos.com wrote: > > I've found that www.xilinx.com is an excellent resource for Spartan > FPGA questions. > That was obviously the first place I looked. > There's a design that uses the board's DRAM here: > <http://www.xilinx.com/products/boards/s3estarter/ > reference_designs.htm> Did I miss it? Which one? The Microblaze based designs don't work for me as I don't have it. > > G. -Alex.Article: 126909
Hello, I have a question about the modular design flow for partial reconfiguration. I created a small pr demo using xilinx modular design flow for a virtex2pro fpga. It consists of 2 static parts with 1 reconfigurable area between. The logic functions of the modules are kept simple stupid. ;-) Intermodule communication happens over a bus macro. All i/o-pads (including the external clock) are located inside the area of the static module on the right side. The one and only clock signal is shared by the reconfigurable module in the middle and the right static module. Following XAPP290 and all pursuing papers I've read, clock signals aren't routed explicitly over bus macros. Thus they are distributed over the global clocking network resources, right? But while active module phase, I encountered the suspicious warning, that PAR has noticed one unrouted signal. Taking a look at the partial netlist inside the FPGA_EDITOR - e.g. the one for the reconfigurable module in the middle - this could be verified. The clock signal was an unrouted net. Is this normal or what am I doing wrong? Shouldn't the clock signal for the reconfigurable module be routed inside its area to an global clock resource connection? I can't imagine, that the obtained partial bitstream from the netlist of the reconfigurable module is going to configure correctly, when the clock signal isn't somehow routed. Could this problem be caused by missing LOC-constraints for the IBUFG and BUFG in the constraint file? Is this necessary at all. Should all I/O-BUFs be LOC-constrainted for partial reconfiguration based on modular design flow? Any suggestions, experiences or in-depth explanations are appreciated. *thx*Article: 126910
On Dec 5, 5:15 pm, MikeShepherd...@btinternet.com wrote: > Many thanks for that. At least I know it isn't seen as a minefield. > > As yet, I don't know what tools are used on the VHDL side. > > Mike There are more than a few quirks in ISE with regard to mixed language design. ModelSim XE won't support it - you need to buy at least the PE version. I've had some issues with synthesis in XST where strange errors cropped up if the VHDL code and the Verilog code both instantiated the same Xilinx primitives. Most of the synthesis problems go away if you package up all of your Verilog into an NGC file and use it as a black box in VHDL (or vice versa). Still I think it's important to have the mixed language simulation tools. Just a matter of money... just my 2 cents GaborArticle: 126911
'rock' The flow described in XAPP290 assumes that you have two working bitstreams, and you have taken their difference to create a partial, which may then be used to go from a working design 1, to a working design 2. I am presuming that since you are complaining about a bitstream that is not working, that it is this "partial" stream modification of the first working design which has the unconnected global clock in FPGA Editor. If design 1 and design 2 had two different global clock resources used (for whatever reason) then this would make sense. The partial bitstream has to way to connect to anything, so loading a partial into FGPGA Editor would leave a lot unconnected... To the extent that the design 2 has a region where it must use the same clock as design 1, somehow the second working design has to "know" how to do this (the LOC constraints you suggest are probably a good way to do that). There is a much newer flow, supported by the new PlanAhead(tm) software tool, that automates this process more gracefully, and leads to a better result. The manual creation of partial bitstreams (original Virtex flow) was difficult, and cumbersome, and was only tolerated by universities and researchers (IMHO). It took the release of PlanAhead to enable the general adoption for the software defined radio partial reconfiguration development to be successful in the marketplace. In spite of the date on this app note, it is actually very old (05/17/02) and may not be the best way to do partial reconfiguration (in light of newer tools). AustinArticle: 126912
Gabor wrote:
> ModelSim XE won't support it - you need to buy at least the
> PE version.
Yes. Simulation licenses are the expensive part.
Starting with *two* modelsim SE vhdl licenses, my choices were
1. upgrade an existing SE vhdl to SE mixed
2. buy one new SE verilog to use with one existing SE vhdl
3. upgrade one SE vhdl to SE language neutral.
This is cheapest but ties up all licenses
during a mixed session.
It might be cheaper for the OP to learn a little vhdl
to cover those 300 LUTs ;)
-- Mike Treseler
Article: 126913austin wrote: > The flow described in XAPP290 assumes that you have two working > bitstreams, and you have taken their difference to create a partial, > which may then be used to go from a working design 1, to a working design 2. Hi Austin, this style of reconfiguration you mentioned in the quode above and talking in your answer is called small bit manipulation flow. this is the second flow described in xapp290. the first one is module-based partial reconfiguration flow. this is the one I refere to. Yeah, I know there is already a newer flow. But I don't have the possibility to use the required tool (PlanAhead) you've mentioned for this new flow. In university we only have the latest EDK and ISE. That's why I'm constrained to apply, experiment and extend the old flow. Tomorrow, I'm going to try to constrain all I/O-BUFs, IBUFG and BUFGs. Maybe this will help. I don't know if the generated partial and full-design bitstreams work. But I would guess the partial ones don't, because the partial netlist generated for the reconfigurable module in active module phase of the flow (2nd phase) has an unrouted clock at the moment. The bitstream generated from this netlist shouldn't work, or do I mess up something? The start configuration (and initial bitstream) for the fpga is generated in the 3rd phase called final assembly in this flow. Anyway, thanks Austin for your effort.Article: 126914
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:iYqdnQldSvpMQsjanZ2dnUVZ_qiinZ2d@comcast.com... > KJ wrote: > > Absolute delays will likely never be synthesizable, for example. > Perhaps you should explain to the makers of discrete delay lines that they are doing the impossible. If you're referring instead to synthesizing a delay inside a programmable part like FPGA (which you probably did) than I'd say that the most likely reason for lack of delay line primitives in FPGAs has more to do with lack of demand for such a feature than it is any technical issues that can't be resolved in a profitable manner for the suppliers....but that's a business decision, not technical. > > On the other hand, if it can be done why not do it as a module. > (That would be verilog, but VHDL has something similar.) > In VHDL speak a module would be an entity...but having a double edge flip flop as an entity is about as useful as a D flip flop primitive (i.e. not very much for the designer writing source code). Instead what is more useful is a known way to reliably write code to perform that function that will work well. The form I chose was deliberately done to demonstrate a technique to that, by simple inspection, can be seen to be functionally equivalent and synthesizable. The better approach for a double edged flop that you'd really like to use in an actual design was demonstrated by Andy and Mike...but as you can see from rickman's misinterpretation it wasn't obvious to him at first glance, whereas my approach was obvious but left him uneasy about using the clock in logic (and rightly so). > Unless the hardware implemented a two edge FF, I don't think > one should synthesize one. It is likely to be slow, exactly what > you don't want in a two edge FF. > Quite possibly true about the speed...but if you're backed into a corner and don't have either a higher speed clock or a PLL you may be forced to make do. KJArticle: 126915
On Dec 6, 5:34 am, axr0284 <axr0...@yahoo.com> wrote: > Alas the design is from somebody else so I don't have the option to re- > write it. Thanks for the insight. I asked this question because it > seems that for 1 net, XST is routing the signal from a DCM on the > right side to a BUFGMUX on the bottom side. This is introducing > additional delays that I would like to remove. I get the following > issue during PAR which i am trying to resolve: > > WARNING:Place:619 - This design either uses more than 8 clock buffers > or uses more than 4 DCMs or has clock buffers > locked to side-BUFG sites or has DCMs locked to side-DCM sites. The > side-DCMs can drive only the BUFGs on the same > side. Since side-BUFGs can drive only their half of the device and > also exclude a global-BUFG from entering a clock > region, it is necessary to partition the clock logic being driven > by these clocks into different clock regions. It > may be possible through Floorplanning all or just part of the logic > being driven by the global clocks to achieve a > legal placement for this design......... > ...... > ........................ > WARNING:Place:620 - A DCM / BUFGCTRL clock component pair have been > found that are not placed at an optimal DCM / > BUFGCTRL site pair. The DCM component <Clock_Tree/SDRAM_CLK_GEN/ > DCM_SP_INST> is locked to site <DCM_X3Y1> and the > corresponding BUFGCTRL component <Clock_Tree/SDRAM_CLK_GEN/ > CLK0_BUFG_INST> is locked to site <BUFGMUX_X2Y1>. This > will not allow the usage of the fast path between the DCM and the > Clock buffer. You may want to analyze why this > problem exists and correct it. This is not an error so processing > will continue. > Phase 4.2 (Checksum:99f58b) REAL time: 23 secs > > Phase 5.30 > ERROR:Place:848 - Automatic clock placement failed. Please attempt to > analyze the global clocking required for this > design and either lock the clock placement or area locate the logic > driven by the clocks so that that the clocks may > be placed in such a way that all logic driven by them may be > routed. The main restriction on clock placement is that > only one clock output signal for any competing Global / Side pair > of clocks may enter any region. For further > information see the "Quadrant Clock Routing" section in the > Spartan3e Family Datasheet. > > It's a pain i the butt :) Thanks for the help > Amish Hi, My two cents on the same issue, I think you should consider using the Floor Planner. I have seen from prior experience that with more that 8 clocks the FPGA tools generally do not do a great job of routing. It helps a lot if you manually place all the BUFGs and DCMs using the Floor planner. It is not that difficult and does not take that much time. Once the DCMs and BUFGs locked, I think you would be able to resolve the problem. In the longer run, I guess somehow you would have to figure a way to modify the design, because design with so many clocks is always a mess, and it throws up all kind so errors/warnings you try to implement it. Have a great day. -- GoliArticle: 126916
MikeShepherd564@btinternet.com wrote: > I have a simple design (about 300 logic elements / 150 registers) > written in Verilog. It's highly self-contained (only about ten > signals on the interface). > > (For the curious, it performs a function for analogue video). > > It's now proposed to incorporate this in a design which is otherwise > VHDL (and over which I shall have no control). > > Obviously, the Verilog could be converted, but this would be > significant work (and I no have no experience at present of VHDL). For > this reason (and particularly since the interface is simple), I'd like > to keep my part of the design in Verilog. > > Is mixed-language design well-supported? If so, does anyone have > general advice or words of caution? > > Mike You'll need a simulator with a license for mixed language, which will generally cost considerably more than a single language license. If your synthesis tool does not support mixed language, you can black box the other language sub-design in the larger design, synthesize them separately and put the edifs in the same directory. The xilinx tools will stitch the edifs together without any problems.Article: 126917
On Dec 5, 6:12 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > Gabor wrote: > > ModelSim XE won't support it - you need to buy at least the > > PE version. > > Yes. Simulation licenses are the expensive part. > Starting with *two* modelsim SE vhdl licenses, my choices were > > 1. upgrade an existing SE vhdl to SE mixed > > 2. buy one new SE verilog to use with one existing SE vhdl > > 3. upgrade one SE vhdl to SE language neutral. > This is cheapest but ties up all licenses > during a mixed session. > > It might be cheaper for the OP to learn a little vhdl > to cover those 300 LUTs ;) > > -- Mike Treseler Yes, ModelSim is the most expensive tool we have. We use both the PowerPCs and the MGTs, so XE was not an option for us. EDK will allow you to simulate a mixed language design with a single language simulator by synthesizing the parts of the design in the language you do not have a license for and generating a post synthesis netlist in the language you do have a license for. That might work for a small part of the design which is already known good. We tried to use that method very briefly before deciding that it was not worth it and upgrading our license. We ended up using ModelSim PE plus with the extra licenses for mixed language, swift models, and code coverage. Other than the difference between how ModelSim and ISE required us to pass parameters, we have not seen any problems with mixing languages. EDK does synthesize each core in the design separately, then combine the netlist in a second pass so maybe that has simplified the situation enough to avoid the problems that Gabor has seen. Even taking how EDK partitions the synthesis, we still have all cases of VHDL using Verilog, and Verilog using VHDL, and having both of them as leaf nodes in the hierarchy of a given core. I have also seen mention of programs to convert Verilog to VHDL and VHDL to Verilog, any one here try them and have any comments on the results? Regards, John McCaskill www.fastertechnology.comArticle: 126918
I know the simple answer will be use NisoII... But in my situation is ..I cannot use NisoII or any other soft/hard core processor (actually is..I am not able to use any asm/c ..whatever computer programing language). I would want to know anyone try to build a FSM to "talk" with the Avalon bus before? What should I do/understand first for build a FSM to work as Master in Avalon bus? My project require to receive packet and put them into memory and then I have another logic to read from the memory. The data flow is that Ethernet --> PHY(chip) --> TSE MAC IP --> Avalon bus --> memory -- >DDR2 controller ->DDR2 memory. What I have now: 1. PCI Express Development Kit, Stratix II GX Edition (http:// www.altera.com/products/devkits/altera/kit-pciexpress_s2gx.html) 2. DDR2 controller demo (non Avalon Bus), (it is work on the PCI Express Development Kit) 3. TSE MAC IP (I did not try it..because all the demo are using NiosII)Article: 126919
KJ wrote: (I wrote) >>Absolute delays will likely never be synthesizable, for example. > Perhaps you should explain to the makers of discrete delay lines that they > are doing the impossible. OK, how about long absolute delays. You can delay some nanoseconds, but I can write a 1s delay in verilog. It would take a very large delay line to do that. > If you're referring instead to synthesizing a delay inside a programmable > part like FPGA (which you probably did) than I'd say that the most likely > reason for lack of delay line primitives in FPGAs has more to do with lack > of demand for such a feature than it is any technical issues that can't be > resolved in a profitable manner for the suppliers....but that's a business > decision, not technical. There are many things I would like to see added to FPGAs before analog delay lines. -- glenArticle: 126920
Ray Andraka wrote: > MikeShepherd564@btinternet.com wrote: >> I have a simple design (about 300 logic elements / 150 registers) >> written in Verilog. It's highly self-contained (only about ten >> signals on the interface). >> It's now proposed to incorporate this in a design which is otherwise >> VHDL (and over which I shall have no control). (snip) >> Is mixed-language design well-supported? If so, does anyone have >> general advice or words of caution? > You'll need a simulator with a license for mixed language, which will > generally cost considerably more than a single language license. If > your synthesis tool does not support mixed language, you can black box > the other language sub-design in the larger design, synthesize them > separately and put the edifs in the same directory. The xilinx tools > will stitch the edifs together without any problems. I once did this with Quartus. I thought the free version did it, but I had a licensed version so I can't be sure. I did mixed AHDL, VHDL, verilog, and schematic capture all in one. With the schematic based parts the ports don't have an order so they all have to be specified by name. Many port names started with a digit, which verilog can do, but it is a little more work. -- glenArticle: 126921
For future reference this is called conditional assignment. Next time you can just google "VHDL conditional assignment". ---Matthew Hicks > Hello > > I am trying to convert the following code to vhdl > > assign Q = (rst==0)?Q_int:1'do; > > How do i convert this to vhdl? I have to use a concurrent statement as > this statement is not in the always block hence concurrent. I cannot > use an if then else statement as it is sequential. > > Please help >Article: 126922
> Phase 5.30 > ERROR:Place:848 - Automatic clock placement failed. Please attempt to > analyze the global clocking required for this > design and either lock the clock placement or area locate the logic > driven by the clocks so that that the clocks may > be placed in such a way that all logic driven by them may be > routed. The main restriction on clock placement is that > only one clock output signal for any competing Global / Side pair > of clocks may enter any region. For further > information see the "Quadrant Clock Routing" section in the > Spartan3e Family Datasheet. I've had a similar problem recently, and it was fixed by LOCking the DCM to the higher side (of a V5) because the tool insisted on placing the DCM at the bottom, and use the BUFGMUX at the top. YMMV w/xc3v -P@Article: 126923
Many thanks for all this advice. MikeArticle: 126924
hmm i'm still struggling with the clock gating. i looked it up in the datasheet again : http://www.xilinx.com/support/documentation/user_guides/ug070.pdf and on page 32 there is the timing diagramm for the bufgce. it appears to me that if the enable signal goes high the next clock edge should bee seen on the output. (if the enable signal is soon enough before that edge of course). but in my simulation it is not. any ideas what i'm doing wrong here or don't understand ?
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