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
Well, 32-bit pointers are half the size of 64-bit pointers, so you would expect less memory to be used, but you wouldn't expect all data structures to double in size as they seem to here. Cache hit rate should be better if half the amount of memory is used, which could explain the improved performance.Article: 154351
Hello to all, I completed my first CPU in VHDL, an incredibly satisfying feeling! : D I simulated successfully but I did not understand what it means to a signal colored red in ModelSim: http://imageshack.us/photo/my-images/824/modelsimproblem.png I notice the signal that is in red has a change of more bits at the same time, it is perhaps hazard or something? How can I eliminate the problem in the case? The register in question is an SRAM synthesized with normal flip-flop, the writing of a data element in memory involves a change of more bits and seems to require two clock pulses to stabilize the signal .. VHDL code: http://www.atomwave.com/FPGA/LCPU.zipArticle: 154352
0LLRgtC+0YDQvdC40LosIDMxINC+0LrRgtGP0LHRgNGPIDIwMDbCoNCzLiwgMjA6MDQ6NDIgVVRD KzMg0L/QvtC70YzQt9C+0LLQsNGC0LXQu9GMIGFyYXZpbmQg0L3QsNC/0LjRgdCw0Ls6DQo+IEhp DQo+ICAgICAgSW0gcGxhbm5pbmcgdG8gZGVzaWduIGFuIFNQRElGIHJlY2VpdmVyIGZvciBpbXBs ZW1lbnRhdGlvbiBvbg0KPiBTcGFydGFuIDMgRlBHQSAsIEJ1dCBpbSBub3Qgc3VyZSBob3cgdG8g Z28gYWJvdXQgdGhlIGRlc2lnbixEb2VzIGFueQ0KPiBvbmUgaGF2ZSBpZGVhcyA/DQo+IFRoYW5r IHUNCg0KSXMgdGhlcmUgYW55IHJlc3VsdHMgb2YgeW91ciBwcm9qZWN0IG5vdz8=Article: 154353
On Friday, October 12, 2012 4:35:44 AM UTC-7, Jon wrote: > Well, 32-bit pointers are half the size of 64-bit pointers, so you would expect less memory to be used, but you wouldn't expect all data structures to double in size as they seem to here. > > Cache hit rate should be better if half the amount of memory is used, which could explain the improved performance. Yes, I know about the pointers ... however I would not expect the data structures to be only pointers :) It's harder to comment about the cache since the performance is dependent of the access pattern .... Still the 64b code is supposed to be better since it has access to more CPU registers. Just for fun, running xst with the simple script: help -arch virtex6 -command run (i.e. print help for run, do nothing). 32b: Total memory usage is 83656 kilobytes 64b: Total memory usage is 274236 kilobytes Interesting .... -- mmihaiArticle: 154354
Yes, I am using the same compiler (gcc 4.2.1) for both versions. I don't have Modelsim SE 10.1c so I cannot try that. As for the other issue, I believe gcc 4.5.0 is for 64 bit Modelsim SE 10.1c. It says in the installation manual file that we should use gcc 4.2.1 for 10.1c 32 bit version. I guess I will continue with Modelsim SE 6.6 release. PS: Modelsim SE 6.6c does not work (initalize the sc_signal vector) either. Thank you for your reply, Hans. >I assume you are using the same compiler version as that sometimes can >also cause issues. If you are not using gcc 4.3.3/4.2.1 (recommended >versions for Linux/win32) then I would try that first. > >If it still fails then try the latest Modelsim SE 10.1c release (gcc >4.5.0/4.2.1) and if that also fails then package up a small testcase >with your code and raise a Service Request. > >You could also try the 2.2 reference simulator just to add some weight >to your SR. > >Good luck, >Hans >www.ht-lab.com --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154355
A red signal means you have an X - an unknown value. Probably something not being reset, or you have multiple drivers, driving different values to the same signal.Article: 154356
Jon wrote: > A red signal means you have an X - an unknown value. Probably > something not being reset, or you have multiple drivers, driving > different values to the same signal. Is it possible to synthesize multiple drivers? When I try this in VHDL, it is an error and it doesn't synthesize the design. Maybe with some "inout" or "buffer" ports? -- Frank Buss, http://www.frank-buss.de electronics and more: http://www.youtube.com/user/frankbussArticle: 154357
On 10/13/2012 4:26 PM, Frank Buss wrote: > Jon wrote: >> A red signal means you have an X - an unknown value. Probably >> something not being reset, or you have multiple drivers, driving >> different values to the same signal. > > Is it possible to synthesize multiple drivers? When I try this in VHDL, > it is an error and it doesn't synthesize the design. Maybe with some > "inout" or "buffer" ports? > That has been my experience with Xilinx tools as well. It's possible that he is simulating RTL and not the post-synthesis data though. BobHArticle: 154358
Frank Buss <fb@frank-buss.de> wrote: > Jon wrote: >> A red signal means you have an X - an unknown value. Probably >> something not being reset, or you have multiple drivers, driving >> different values to the same signal. > Is it possible to synthesize multiple drivers? When I try this in VHDL, > it is an error and it doesn't synthesize the design. Maybe with some > "inout" or "buffer" ports? Earlier Xilinx FPGAs had internal tristate buffers. As the chips got bigger, it became necessary to put buffers along the lines, and so internal tristates were removed. Even so, the tools usually will generate equivalent logic. -- glenArticle: 154359
On 10/13/2012 11:09 PM, glen herrmannsfeldt wrote: > Frank Buss <fb@frank-buss.de> wrote: >> Jon wrote: >>> A red signal means you have an X - an unknown value. Probably >>> something not being reset, or you have multiple drivers, driving >>> different values to the same signal. > >> Is it possible to synthesize multiple drivers? When I try this in VHDL, >> it is an error and it doesn't synthesize the design. Maybe with some >> "inout" or "buffer" ports? > > Earlier Xilinx FPGAs had internal tristate buffers. As the chips > got bigger, it became necessary to put buffers along the lines, > and so internal tristates were removed. Even so, the tools > usually will generate equivalent logic. > > -- glen > They won't generate any logic if more than one process drives the same line and it's not an inout port of each driver. Synthesis is therefore an easy way to check for multi-source errors. I almost never simulate code intended for synthesis unless I have run it through synthesis first. You can spend a lot of time debugging stuff and then realize you need to start over because you used a non-synthesizable "feature" of the language. -- GaborArticle: 154360
Here are some more links regarding counter & accumulator carry techniques. -------------------- Links to early Xilinx counter app notes: Ultra-Fast Synchronous Counters in XC3000 & XC4000 FPGAs http://www.cs.york.ac.uk/rts/docs/Xilinx-datasource-2003-q1/appnotes/xapp014.pdf Loadable Binary Counters in a XC3000 FPGA http://www.cs.york.ac.uk/rts/docs/Xilinx-datasource-2003-q1/appnotes/xapp004.pdf pages 15-18 of Xcell Journal #7 http://www.xilinx.com/publications/archives/xcell/Xcell7.pdf -------------------- Haven't found a pdf for XAPP 001 yet: " " High-Speed Synchronous Prescaler Counter " (XAPP 001) " " This simple design provides a very basic non-loadable, " up counter with a count-enable control. However, this " simplicity permits it to be both the densest and the " second fastest design. " " A prescaler (CEP/CET) technique is used to gain speed, " permitting the ripple-carry portion of the counter " eight clock periods in which to settle. Without special " adaptation, however, this technique precludes loading " the counter. As a non-loadable counter, three bits can " be implemented in three CLBs (1 CLB/bit), with the least " significant six bits requiring only four CLBs; this " explains the compactness. Only one TILO delay is incurred " in the ripple-carry path for each three bits. " This technique of making the low N bits run fast, with the upper bits running slower by 2^N, should map well into a compact yet fast implementation of a non-loadable binary counter for your Actel part. I.e., use something like the pcounter scheme for the low few bits, then make the upper bits with a ripple carry, enabled by the carry out of the low bits. You probably will need to add special timing constraints to get the tools to understand the multicycle carry, and that the ripple chain is a false path after FF reset. The advantage of this is that you would now only need to deskew N LSB's of the counter for straight binary output. -------------------- ORCA-3 FPGAs had an optional register in the dedicated carry chain: " Fast-carry logic and routing to adjacent PFUs for " nibble-wide, byte-wide, or longer arithmetic functions, " with the option to register the PFU carry-out. -------------------- More carry-pipelined accumulator references: ( I've mentioned accumulators because they are a more general carry design problem than are counters, and because I know where to look for literature describing high speed pipelined versions.) "Direct Digital Synthesizers: Theory, Design and Applications", Vankka lib.tkk.fi/Diss/2000/isbn9512253186/isbn9512253186.pdf See pages 48-49 for accumulator pipelining techniques. "Single Chip 500 MHz Function Generator" P.H. Saul, W. Barber, D.G. Taylor, T. Ward IEE Proceedings, Vol. 138, No. 2, pp 239-243, April 1991 Reprinted in "Direct Digital Frequency Synthesizers", Kroupa (ed), IEEE Press, 1999 Fig. 2 shows the one-bit-per-carry accumulator structure Fig. 5 shows the accumulator output deskew tree -BrianArticle: 154361
On 10/10/12 1:10 AM, bln5320@googlemail.com wrote: > Sorry I was not at work the last days. Thank you very much for the answers and your care. > I will do as you say and look for a board with Xilinx ISE. > The Diligent Boards are looking good. > I think it will be the Spartan 3E Starter Board: > http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,792&Prod=S3EBOARD > Or the Atlys™ Spartan-6 FPGA Development Board > http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS > > Do I need an Gigabit-Ethernet PHY? If you're doing gigabit Ethernet, then yes. Note that most gigabit PHYs also work at 10 and 100 Mbps. > Do I need 2 RJ-45 Interfaces? Depends on what you want to do with it. > Or can I connect the UTP Cable directly the the FPGA pins. You can certainly connect a UTP cable directly to an FPGA (like you could with any piece of wire), but it might not do what you want. High speed Ethernet usually uses a parallel interface (GMII/MII, etc.) that the PHY converts to one of the physical layer Ethernet standards. Most FPGAs aren't capable of generating the correct logic levels necessary for Ethernet directly, which is why you need a PHY. > Or something like UTP to RJ-45 and the PC with usb? Not sure what you mean by that! > For further Information about the used ethernet you can look at the Figure 5 its the Broadcom Ethernet > http://itersnews.com/?p=10541 If you want to use Automotive Ethernet, I would recommend that you use an Automotive Ethernet PHY. They're not very common on FPGA development boards, so you might need to do some PCB design for this. JoelArticle: 154362
On Sunday, October 14, 2012 1:55:03 PM UTC-5, Gabor wrote: They won't generate any logic if more than one process drives the same line and it's not an inout port of each driver. That's not correct. All you need is an OUT port, a resolved type, and conditionally drive 'Z' on that port. INOUT has nothing to do with it, unless you want to read the result of the (resolved) bus inside one of the modules that drives it. AndyArticle: 154363
Thank you to all, Thank you very much for your valuable informations. I've adjusted code and removed red warning in Modelsim with: case state is -- ... when sexec => -- Read data case data(7 downto 6) is -- ... -- Store when "01" => we <= '1'; addr <= data(5 downto 0); state <= sstore; -- ... end case; when sstore => -- write to memory, data is ready next clock data <= reg; state <= sfetch; when others => null; end case; I just moved: data <= reg; In the state sstore. So using high impedance Z signals in design is a worst practice? Thank youArticle: 154364
On Monday, October 15, 2012 9:42:17 AM UTC-5, flz47655 wrote: > So using high impedance Z signals in design is a worst practice?=20 Not necessarily. Some work groups or organizations discourage it. If I use = it (inside an FPGA, instead of on IO), I heavily comment what is supposed t= o happen, and perhaps why a more explicit approach is not preferable.=20 A fuzzy area is called "pushing tri-states" (through registers). We often n= eed registered, tri-stated IO, and an easy (to read and write) way to do it= is to assign 'Z's to the output register. Of course registers cannot reall= y hold a 'Z', but the synthesis tool recognizes this, inserts a tri-state b= uf after the register AND inserts a register for the (implied) tri-state bu= f enable signal. Note that if you reset a register to 'Z', then the real re= set on the real data register is not truly defined. The RTL code still dete= rmines what the first (non-Z) assignment after reset will be, so it really = does not matter. I don't recall whether the synthesis tool left the data re= gister reset off, or defaulted the reset value to '0'. I would imagine that= if it affects pushing the registers et al into the IO block (e.g. if all r= egisters in the IOB must have a common reset), the synthesis tool will "do = the right thing". Inside an FPGA, an interesting side-effect of tri-state to mux synthesis is= that the tri-state enable signals are assumed to be mutually exclusive (ot= herwise it would not have worked for a real tri-state bus), which reduces t= he complexity of the mux. This may be an easier way to get the simpler mux = than to explictly code the AND-OR tree. It also allows the mux control/code= to be distributed amongst multiple modules. The same can be done with at l= east the AND gating of an explicilty coded AND-OR tree. Also, an INOUT tristate port on an internalal bus/module is automatically i= mplemented as three signals (an output & enable to the mux, and an input fr= om the mux). Whether that is more readable/writeable/maintainable than a mo= re explicit description with two ports and an external mux is dependent upo= n the application and the design team/customer. (YMMV) If the application a= llows, I tend to favor higher levels of abstraction over more explicit desc= riptions of hardware. AndyArticle: 154365
flz47655 wrote: > So using high impedance Z signals in design is a worst practice? You need it, if you want to implement an open collector output, e.g. for implementing I2C. I've never needed it inside a FPGA. -- Frank Buss, http://www.frank-buss.de electronics and more: http://www.youtube.com/user/frankbussArticle: 154366
On 10/15/2012 10:12 AM, jonesandy@comcast.net wrote: > On Sunday, October 14, 2012 1:55:03 PM UTC-5, Gabor wrote: > They won't generate any logic if more than one process drives the same line and it's not an inout port of each driver. > > That's not correct. All you need is an OUT port, a resolved type, and conditionally drive 'Z' on that port. INOUT has nothing to do with it, unless you want to read the result of the (resolved) bus inside one of the modules that drives it. > > Andy Like someone said earlier, FPGAs no longer have tristate buffers in them. If this is an external pin, then a 'Z' can be driven, but I'm still not sure it will synthesize with multiple drivers. RickArticle: 154367
On 10/15/2012 10:12 AM, jonesandy@comcast.net wrote: > On Sunday, October 14, 2012 1:55:03 PM UTC-5, Gabor wrote: > They won't generate any logic if more than one process drives the same line and it's not an inout port of each driver. > > That's not correct. All you need is an OUT port, a resolved type, and conditionally drive 'Z' on that port. INOUT has nothing to do with it, unless you want to read the result of the (resolved) bus inside one of the modules that drives it. > > Andy > On the other hand if one process is assigning 'Z', then he shouldn't get 'X' on the simulation. My point was that a normal signal can't generally be driven by more than one process for synthesis within the same entity or architecture. In Verilog this is certainly enforced for "reg" types, whether they are assigned 'Z' or not. None of this is an error for simulation, and unless you happen to notice the 'X' for the multiple-driven case, you could do a lot of design debug and then realize you need to do a lot of re-coding to get it to synthesize. -- GaborArticle: 154368
We proudly announce the 9th annual Digilent Design Contest Europe, organize= d within the Technical University of Cluj-Napoca, Rom=E2nia and sponsored b= y Digilent! The goal of this international student contest is to encourage students to = develop their engineering hardware and software skills. We invite teams of = students (one or two members) from all over Europe, to put in practice thei= r ideas. Teams will have approximately 6 months to design and implement a p= roject (FPGA or microcontroller) of their choice and present the final vers= ion in May 2013 in Cluj-Napoca, Rom=E2nia.=20 Students will be provided state-of-the-art Digilent FPGA or microcontroller= boards as well as peripheral modules to develop their projects. Please vis= it our website: http://www.digilent.ro to see all our products, especially= the ones recommended for this year competition. Visit us on the web for more information about the European Contest or writ= e to: contestEU@digilentinc.com=20 The most creative and complex solutions are rewarded with generous prizes!= =20 Please forward this information to university students, especially from com= puter science or electrical engineering majors. We would appreciate receivi= ng a feedback about whether this information presents any interest for you = or not. Apart from the Digilent Contest Europe, there will be regional editions of = the contest, to which you can apply. We encourage students to enroll in the= regional contest that is convenient for them. More information about the e= vent can be found at http://www.digilentinc.com/events/ddc2013/. Also see o= ur previous events and the successful Munich Worldwide Finals. Sincerely, The Digilent TeamArticle: 154369
>=20 > > Sorry I was not at work the last days. Thank you very much for the answ= ers and your care. >=20 > > I will do as you say and look for a board with Xilinx ISE. >=20 > > The Diligent Boards are looking good. >=20 > > I think it will be the Spartan 3E Starter Board: >=20 > > http://www.digilentinc.com/Products/Detail.cfm?NavPath=3D2,400,792&Prod= =3DS3EBOARD >=20 > > Or the Atlys=EF=BF=BD Spartan-6 FPGA Development Board >=20 > > http://www.digilentinc.com/Products/Detail.cfm?NavPath=3D2,400,836&Prod= =3DATLYS >=20 > > >=20 > > Do I need an Gigabit-Ethernet PHY? >=20 >=20 >=20 > If you're doing gigabit Ethernet, then yes. Note that most gigabit PHYs= =20 >=20 > also work at 10 and 100 Mbps. >=20 >=20 >=20 > > Do I need 2 RJ-45 Interfaces? >=20 >=20 >=20 > Depends on what you want to do with it. >=20 >=20 >=20 > > Or can I connect the UTP Cable directly the the FPGA pins. >=20 >=20 >=20 > You can certainly connect a UTP cable directly to an FPGA (like you=20 >=20 > could with any piece of wire), but it might not do what you want. High=20 >=20 > speed Ethernet usually uses a parallel interface (GMII/MII, etc.) that=20 >=20 > the PHY converts to one of the physical layer Ethernet standards. Most=20 >=20 > FPGAs aren't capable of generating the correct logic levels necessary=20 >=20 > for Ethernet directly, which is why you need a PHY. >=20 >=20 >=20 > > Or something like UTP to RJ-45 and the PC with usb? >=20 >=20 >=20 > Not sure what you mean by that! >=20 >=20 >=20 > > For further Information about the used ethernet you can look at the Fi= gure 5 its the Broadcom Ethernet >=20 > > http://itersnews.com/?p=3D10541 >=20 >=20 >=20 > If you want to use Automotive Ethernet, I would recommend that you use=20 >=20 > an Automotive Ethernet PHY. They're not very common on FPGA development= =20 >=20 > boards, so you might need to do some PCB design for this. >=20 >=20 >=20 > Joel Thank you.=20 I've got an automtive phy now, so i have to implement the MAC Layer on the = FPGA and thats it. I've found the opencores at opencores.org So Thank you very much :)Article: 154370
In vhdl, you can use unresolved data types to disallow multiple drivers. You can still drive 'Z' with std_ulogic or std_ulogic_vector, but you can only have one driver. I seem to remember Modlesim showing waves in red if the trace included meta-values (W, Z, X, -, U), maybe if you had the radix set to something besides binary? If that is the case, it would not necessarily indicate contention between drivers. AndyArticle: 154371
Alright, I've got to fess up. I'm lost as to the point of .do files. They seem to suffer through all of Tcl's wacky syntax, but with the added benefit of not giving you access to the standard Tcl commands. Am I missing something here? Or is the entire point of the exercise that Tcl is considered to be intimidating, whereas a proprietary macro language is not? -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 154372
jonesandy@comcast.net wrote: > In vhdl, you can use unresolved data types to disallow multiple drivers. You can still drive 'Z' with std_ulogic or std_ulogic_vector, but you can only have one driver. > > I seem to remember Modlesim showing waves in red if the trace included meta-values (W, Z, X, -, U), maybe if you had the radix set to something besides binary? If that is the case, it would not necessarily indicate contention between drivers. > > Andy Modelsim (in the default color scheme) shows Z in blue and most other meta-values in red. If any bits of a vector are not 0, 1 or Z, then the whole vector gets colored red unless you expand it to show individual bits. This has nothing to do with the display radix. You can see binary values like "01XX0XX0" in the waveform originally posted. Just under it you can see the individual bits as waves, and only those with "X" values show up in red. If you have a sufficient license (I don't think the vendor-bundled editions did this) you can double-click on the red lines to trace back to the driver(s). And the multi-driver issue was a "side-thread" to this topic. There are many ways to end up with X or U in simulation. -- GaborArticle: 154373
I'm working on a Virtex 5 project containing a 13-stage pipeline clocked at 200 MHz. The data path gets quite wide in the latter stages; but only 11% of available slices are used; so the FPGA is relatively empty. Every other step in the build process rips through quickly, except the above named MAP stage, which accounts for 98% of total build time. Routing is over in a flash, and the result meets timing. I would like to reduce the build time and I was wondering how to go about it. One idea was to create LOC constraints on logic, perhaps based on where the tools themselves placed it after a previous optimization run. Any other suggestions? TIAArticle: 154374
In article <20121016103951.01e68467@rg.highlandtechnology.com>, Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: >Alright, I've got to fess up. I'm lost as to the point of .do files. >They seem to suffer through all of Tcl's wacky syntax, but with the >added benefit of not giving you access to the standard Tcl commands. > >Am I missing something here? Or is the entire point of the exercise >that Tcl is considered to be intimidating, whereas a proprietary macro >language is not? If you're talking about Modelsim - I was under the impression that they were one in the same. We seem to name our modelsim scripts haphazardly - some .tcl, some .do Perhaps .tcl is intended for pure tcl, and .do is intended for "tcl" plus modelsim builtins? I dunno. Never given it too much thought... --Mark
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