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
Rick, > These circuits are typically FSM, counters and the like. > Normally the data path does not care about reset since it > will immediately go to the correct state on the next clock. I am a former ASIC designer. I think I understand this part well. I do have a couple concerns. First I want a reset methodology that is device independent and simulates well for any ASIC or FPGA technology not just specific to Xilinx. Hence, everything that requires reset will need the synchronized reset. I agree most data path does not need reset (except for on some ASIC designs to get the device to pass vectors more easily on the tester). My second concern is that selective reset is not for everyone. For some this methodology will cause chaos. For a design review with selective reset, this is just one more item that needs to be reviewed in detail. > One circuit you can add to any FSM to provide a sync reset is just one > or a pair of FFs which work just like a metastability reduction > circuit. Have the GSR hold these FFs in the '1' state and wire the D > input of the first one to a '0'. The last output will be your sync > reset. The sync reset will be held for one or two clock edges after the > release of GSR. This will only need to be used by the first two bits of > a one-hot FSM, the first changed bit of a gray coded counter, the first > bit of a JRC or even the first bit of a binary counter (assuming it > starts at 0); and so will not overly complicate them and slow them > down. To me this seems like Chaos**n. Not that it will not work, it just adds more details you need to manage. This methodology would have to buy me something significant (speed or device size) for me to want to do additional analysis and verification to prove that a circuit designed as above actually works under all conditions. >>If this is possible, is there a VHDL coding methodology >>that you can recommend? The big missing piece for me >>is how do I access the output of GSR? > > > This is something that should be added to Peter's app note. > > >> #1: Explicitly through instantiation? >> #2: Implicitly through initializing the VHDL >> signals that create the registers? >> Although this technique seems possible in XST, >> would it also work the same in other synthesis tools? >> #3: Put the reset logic in a separate hierarchical >> block and explicitly code an asynchronous reset, but >> at the next level of the design tie the asynchronous >> reset to a constant inactive value? > > > You don't need to access the GSR signal explicitly. If you provide an > async reset control that is common to most/all of your sequential logic, > I believe the tools will infer the GSR. > > run_en_reg: PROCESS (sysclk, reset) BEGIN > IF (reset = '1') THEN > run_en <= '0'; > ELSIF (rising_edge(sysclk)) then > run_en <= '1'; > END IF; > END PROCESS; This sounds like it would address my needs nicely. What do you connect reset to? Do you just leave it floating? What do you do with it in simulation? If there is something here that would work with XST, Synplicity, and Mentor, without changing the code, this would make me happy. Especially if the only thing I needed to change for each FPGA/ASIC technology is the reset block and where the power-on reset comes from. > You can learn a lot about it by reading how the end of configuration > works. But the main thing is to stop assuming that the end of GSR is a > synchronous event. On other chips we get used to the reset just working > (like magic). In the FPGA we need to give it a little thought, even if > it is not really hard. On ASICs reset is explicit. On your flow above with Xilinx, I code reset on the register, hook it to ?? or leave it unconnected, and then "magically" it gets connected to GSR. Is there a datasheet, manual, or appnote you recommend reading on configuration. Cheers, Jim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 71326
Let me get back to the fundamental problem: We distribute a (p)reset signal all over the chip. The problem is not the activating edge of this signal, it's the release of (p)reset. No matter how we distribute and phase it (unless there is only a single user clock of relatively low frequency) the trailing edge will not appear at every flip-flop in the same clock period. Whether the (p)reset is asynchronous or synchronous does not matter. I do not see a way to solve this dilemma on the chip-hardware-design level. I suppose the software could be made smart enought to handle this, same as smart designers can design around this. Especially with an elegant construct like SRL16. Peter Alfke > From: Jim Lewis <Jim@SynthWorks.com> > Organization: Posted via Supernews, http://www.supernews.com > Newsgroups: comp.arch.fpga,comp.lang.vhdl > Date: Wed, 14 Jul 2004 12:01:13 -0700 > Subject: Re: FSM in illegal state (conclusion) > > Rick, >> These circuits are typically FSM, counters and the like. >> Normally the data path does not care about reset since it >> will immediately go to the correct state on the next clock. > I am a former ASIC designer. I think I understand this > part well. I do have a couple concerns. First I want a > reset methodology that is device independent and > simulates well for any ASIC or FPGA technology not > just specific to Xilinx. Hence, everything that requires > reset will need the synchronized reset. I agree most > data path does not need reset (except for on some ASIC designs > to get the device to pass vectors more easily on the tester). > > My second concern is that selective reset is not for > everyone. For some this methodology will cause chaos. > For a design review with selective reset, this is just > one more item that needs to be reviewed in detail. > > >> One circuit you can add to any FSM to provide a sync reset is just one >> or a pair of FFs which work just like a metastability reduction >> circuit. Have the GSR hold these FFs in the '1' state and wire the D >> input of the first one to a '0'. The last output will be your sync >> reset. The sync reset will be held for one or two clock edges after the >> release of GSR. This will only need to be used by the first two bits of >> a one-hot FSM, the first changed bit of a gray coded counter, the first >> bit of a JRC or even the first bit of a binary counter (assuming it >> starts at 0); and so will not overly complicate them and slow them >> down. > To me this seems like Chaos**n. Not that it will not work, > it just adds more details you need to manage. > > This methodology would have to buy me something significant > (speed or device size) for me to want to do additional > analysis and verification to prove that a circuit designed > as above actually works under all conditions. > > >>> If this is possible, is there a VHDL coding methodology >>> that you can recommend? The big missing piece for me >>> is how do I access the output of GSR? >> >> >> This is something that should be added to Peter's app note. >> >> >>> #1: Explicitly through instantiation? >>> #2: Implicitly through initializing the VHDL >>> signals that create the registers? >>> Although this technique seems possible in XST, >>> would it also work the same in other synthesis tools? >>> #3: Put the reset logic in a separate hierarchical >>> block and explicitly code an asynchronous reset, but >>> at the next level of the design tie the asynchronous >>> reset to a constant inactive value? >> >> >> You don't need to access the GSR signal explicitly. If you provide an >> async reset control that is common to most/all of your sequential logic, >> I believe the tools will infer the GSR. >> >> run_en_reg: PROCESS (sysclk, reset) BEGIN >> IF (reset = '1') THEN >> run_en <= '0'; >> ELSIF (rising_edge(sysclk)) then >> run_en <= '1'; >> END IF; >> END PROCESS; > > This sounds like it would address my needs nicely. > What do you connect reset to? Do you just leave > it floating? What do you do with it in simulation? > > If there is something here that would work with > XST, Synplicity, and Mentor, without changing the > code, this would make me happy. Especially if > the only thing I needed to change for each FPGA/ASIC > technology is the reset block and where the power-on > reset comes from. > > >> You can learn a lot about it by reading how the end of configuration >> works. But the main thing is to stop assuming that the end of GSR is a >> synchronous event. On other chips we get used to the reset just working >> (like magic). In the FPGA we need to give it a little thought, even if >> it is not really hard. > On ASICs reset is explicit. On your flow above with Xilinx, > I code reset on the register, hook it to ?? or leave it > unconnected, and then "magically" it gets connected to GSR. > > Is there a datasheet, manual, or appnote you recommend reading > on configuration. > > Cheers, > Jim > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jim Lewis > Director of Training mailto:Jim@SynthWorks.com > SynthWorks Design Inc. http://www.SynthWorks.com > 1-503-590-4787 > > Expert VHDL Training for Hardware Design and Verification > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 71327
Jim Lewis wrote: > > Rick, > > These circuits are typically FSM, counters and the like. > > Normally the data path does not care about reset since it > > will immediately go to the correct state on the next clock. > I am a former ASIC designer. I think I understand this > part well. I do have a couple concerns. First I want a > reset methodology that is device independent and > simulates well for any ASIC or FPGA technology not > just specific to Xilinx. Hence, everything that requires > reset will need the synchronized reset. I agree most > data path does not need reset (except for on some ASIC designs > to get the device to pass vectors more easily on the tester). > > My second concern is that selective reset is not for > everyone. For some this methodology will cause chaos. > For a design review with selective reset, this is just > one more item that needs to be reviewed in detail. I don't design huge devices. I also normally need to conserve gates. So I typically am working close to the hardware. This selective reset (as you call it) is just SOP for me. I don't use test vectors (can't you provide don't cares?) and the chaos is only if you don't use it correctly. But all of this is only to save gates and/or improve speed. Trying to route a chip wide sync reset can end up running into the same timing issues as the async reset if the fanout is too large. I once worked on an Altera design where we had CEs with large fanouts at 80 MHz. The timing analysis software did not work correctly for these signals and we had a he77 of a time getting the chip to actually work on the bench when the software said all was well. Being 80% full didn't help much either. But my point is that chip wide, large fanout signals can be problematic. So I make sure I understand what my chip needs to startup correctly and deal with that. Of course ASIC design requires a whole different level of confidence, but the method is not any different for an ASIC. You just have to make sure you did your homework, just like when you design your FSM in the first place. A small mistake in the FSM can work great in simulation and even on the test bench, but end up failing in the field and lock up the whole thing. I can vouch for that. > > One circuit you can add to any FSM to provide a sync reset is just one > > or a pair of FFs which work just like a metastability reduction > > circuit. Have the GSR hold these FFs in the '1' state and wire the D > > input of the first one to a '0'. The last output will be your sync > > reset. The sync reset will be held for one or two clock edges after the > > release of GSR. This will only need to be used by the first two bits of > > a one-hot FSM, the first changed bit of a gray coded counter, the first > > bit of a JRC or even the first bit of a binary counter (assuming it > > starts at 0); and so will not overly complicate them and slow them > > down. > To me this seems like Chaos**n. Not that it will not work, > it just adds more details you need to manage. Yes, more details, but each one is separate. If you have startup dependancies between your FSMs, that has to be managed even if you have a global sync reset. This does not change that. > This methodology would have to buy me something significant > (speed or device size) for me to want to do additional > analysis and verification to prove that a circuit designed > as above actually works under all conditions. Speed is just what it is about. If you have to add another input to every FF on the chip (some of which don't have a lut if they are just delay registers) I can assure you that many of them will end up adding a layer of logic and therefore another increment of delay. If your design is not timing critical, then this is not an issue. > >>If this is possible, is there a VHDL coding methodology > >>that you can recommend? The big missing piece for me > >>is how do I access the output of GSR? > > > > > > This is something that should be added to Peter's app note. > > > > > >> #1: Explicitly through instantiation? > >> #2: Implicitly through initializing the VHDL > >> signals that create the registers? > >> Although this technique seems possible in XST, > >> would it also work the same in other synthesis tools? > >> #3: Put the reset logic in a separate hierarchical > >> block and explicitly code an asynchronous reset, but > >> at the next level of the design tie the asynchronous > >> reset to a constant inactive value? > > > > > > You don't need to access the GSR signal explicitly. If you provide an > > async reset control that is common to most/all of your sequential logic, > > I believe the tools will infer the GSR. > > > > run_en_reg: PROCESS (sysclk, reset) BEGIN > > IF (reset = '1') THEN > > run_en <= '0'; > > ELSIF (rising_edge(sysclk)) then > > run_en <= '1'; > > END IF; > > END PROCESS; > > This sounds like it would address my needs nicely. > What do you connect reset to? Do you just leave > it floating? What do you do with it in simulation? That depends on the target and tools. Many HDL packages will detect the async reset and connect it to the GSR, similar to the way they detect clock signals and use the global clock buffers. Some may still require instantiation of an internal async reset signal source. Check with your tool/chip vendor. > If there is something here that would work with > XST, Synplicity, and Mentor, without changing the > code, this would make me happy. Especially if > the only thing I needed to change for each FPGA/ASIC > technology is the reset block and where the power-on > reset comes from. The above style is what I learned to use before anyone was providing any automatic support. You used to need to instantiate the driver for this signal or even provide it at a schematic level at the top of the design. As far as I know all vendors support this, but check with the tool vendor to be sure. Don't they have style guides? > > You can learn a lot about it by reading how the end of configuration > > works. But the main thing is to stop assuming that the end of GSR is a > > synchronous event. On other chips we get used to the reset just working > > (like magic). In the FPGA we need to give it a little thought, even if > > it is not really hard. > On ASICs reset is explicit. On your flow above with Xilinx, > I code reset on the register, hook it to ?? or leave it > unconnected, and then "magically" it gets connected to GSR. > > Is there a datasheet, manual, or appnote you recommend reading > on configuration. I don't know which app note would be good, but Xilinx has lots of them. Do a doc search on their web site on the line of chips you are using and the word "startup" or "configuration". -- 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: 71328
Maybe I am being a little dense, but I can't find anything on this in my VHDL books and the LRM is pretty esoteric in this section. I am writing some code to help me simplify simulation data display and I want to have some SLV constants in an array. These constants relate to defined states of a combination of signals and have names associated with them. To get the names to show up in the simulation, I want to use an enumerated type which then corresponds to the index of the constant array. Can I directly use this enumerated type as the index? I am still a day or so from having some code to try. Am I barking up the wrong tree with this? Should I convert my enum variable to an int and use that as the array index? subtype ALUSLV is SLV07; subtype ALUTyp is (AD, ADC, SU, SUC, CM, CMC, AN, LOR, LXR, SR, SC, AER); type ALUstyles is array (ALUTyp) of ALUSLV := ( "00100XX", ... -- 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: 71329
I suppose you could use an SPI flash in conjuction with a cheap up like a PIC (some of those are less than a dollar,
and they even have one in a SOT23 package) to undercut the cost of the serial config ROMs.
--
--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: 71330
I'm coming a little late to this conversation, but perhaps this has not been
considered.
I sincerely doubt it is a configuration problem. Much more likely, you are not
coming
out of reset at the end of configuration cleanly. The global reset must be
considered
asynchronous to the clock. Most likely, you are occasionally getting a
situation where
one or more flip flops are seeing the end of the configuration reset a clock
cycle before
or after other flip flops in a critical area of your design. Simulation usually
won't catch
this, so you need to do a careful examination of the start up of your design. I
can't tell you
the number of designs I've seen that make this common mistake, even from FPGA
board
vendors with much experience that really should know better.
Check the state machines in your design. The resets for them should come from a
flip-flop in the design that feeds all the reset inputs to the state machine.
You can't
depend on global reset going away on all flip-flops during the same clock cycle.
Antti Lukats wrote:
> "Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message
> news:3vpde0p9u98hlop2aucsd27b11b919h8i8@4ax.com...
> > On Sat, 3 Jul 2004 18:54:16 -0700, "Antti Lukats" <antti@case2000.com>
> > wrote:
> >
> > <stuff snipped>
> > >its not funny to simulate Full 1M Gate with MicroBlaze !
> >
> > Does this mean it wasn't simulated?
>
> yes it means that the 1M gate desing with 32K application code for
> Microblaze has not bein simulated. All the custome IP cores connected to
> Microblaze of course have been simulated.
>
> > > and you can not simulate badly configured FPGA anyway, can you?
> >
> > No, but it remains to be seen whether that's the problem. If you
> > haven't simulated, start there.
>
> Dear Bob,
>
> I have a bitstream that starts always OK when loaded from configuration
> memory, and start with erratic behaviour 1 from 100 JTAG configuration
> attempts (even when JTAG configuration did not show any error during
> download). When the bitstream starts badly it behavies badly after reset
> also, only full new reconfiguration makes the system to working again. So I
> do assume it is possible that the CRC check is not sufficent in Virtex2
> devices and that they actually do start also in case of bad download
> sometimes.
>
> You suggested this erratic behaviour of bad starting when loading from JTAG
> could be found running simulations ?! Well I really cant understand that any
> simulation models could take into account the errors that happend during
> download. ?? Or what was it what I could possible find in simulation?
>
> Antti
--
--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: 71331On Wed, 14 Jul 2004 08:10:16 GMT, Pete Harrison <peter_harrison@ntlworld.com> wrote: [snip...snip...] >I have just tried this and it works a treat. Luckily, the other outputs >are all free in this circuit. > >I also tried the shortcut: > >Pin [12..15] = [Q3..0]; /** **/ >Pin [16..19] = [Y3..0]; > >field output = [Q3..0]; >field stpctrl = [Y3..0]; > >/* state machine stuff */ > >output = ENA & stpctrl; > >Which works just fine Ah! I'd forgotten fields; knew there had to be *some* way to avoid having to list them explicitly. >Thank you so much. I have no idea where you are so you will have to make >do with a couple of virtual beers (or whatever you prefer) Beer is fine; thanks! I'm in the midst of a week of grunting through some reliability paperwork (FMECA, ugh) so a small potation is welcome. -- Rich Webb Norfolk, VAArticle: 71332
Just FYI, there is an application note on this very topic that demonstrates how to configure a Xilinx FPGA from an SPI serial Flash using a small CPLD. The application note is written for CoolRunner-II, but practically any Xilinx CPLD will do. XAPP800: Configuring Xilinx FPGAs with SPI Flash Memories Using CoolRunner-II CPLDs http://www.xilinx.com/bvdocs/appnotes/xapp800.pdf While we're on the subject, have you ever wanted to store additional information in the configuration memory (serial numbers, Ethernet MAC IDs, MicroBlaze code) and read it after the FPGA configures? If so, the following application note may be of interest. XAPP694: Reading User Data from Configuration PROMs http://www.xilinx.com/bvdocs/appnotes/xapp694.pdf The two demo designs for the Spartan-3 Starter Kit also demonstrate this capability. http://www.xilinx.com/products/spartan3/s3boards.htm#RF --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASIC "Ray Andraka" <ray@andraka.com> wrote in message news:40F5AEB8.DDDC48C9@andraka.com... > I suppose you could use an SPI flash in conjuction with a cheap up like a PIC (some of those are less than a dollar, > and they even have one in a SOT23 package) to undercut the cost of the serial config ROMs. > > > -- > --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: 71333
Hi, there: My active implementation of two modules are all correct, P&R are perfect. However, during assembly stage, a small number (4) of wires literally got unrouted and returned to green flywires after P&R is done. In the fpga_editor it is labeled as GLOBAL_LOGIC0, and it lies deep in the middle of the reconfigurable module's AREA_GROUP...On inspecting active implementation, this wire IS routed, and the individual modules are perfectly routed too... What may I do with this? Thanks. CodyArticle: 71334
Austin, > >Wow. Sooooo much current! > Save your sarcasm for an instance in which it is merited. Peter's claim of "zero additional system power" was inaccurate, especially coming after the "urban legend" lead-in. If he has a problem with me pointing out the per bank overhead of DCI for V2 and S3 parts, I'm sure he'll speak up about it. In a small Spartan3 design drawing little current on VCCINT, power consumption would be dominated by "sooooo much current", especially if using 33 ohm VRP/N resistors as you suggested earlier in the thread. It would be much better to shut down the VRP/VRN outputs after configuration when DCIUpdateMode=Quiet, which would eliminate the DCI power overhead completely for series DCI. When last I checked in detail (Fall 2003), all of Xilinx's power estimation tools, published data, and Answer Records failed to properly report static DCI supply current, for both per-bank overhead and per-input parallel termination. As for the rest of your post, I could point out in detail the various errors and omissions you've made, but I don't have the time or patience tonight to explain things that should have been properly documented in the Virtex2 application notes and datasheets long ago. Brian Austin Lesea <austin@xilinx.com> wrote in message news:<cd3o2s$npd3@cliff.xsj.xilinx.com>... > >Brian, > >LVDCI_33 is 60 mA for the reference resistors. For the whole bank. > >Wow. Sooooo much current! Face it: setting the reference for the >entire bank does take some power (in this case 3.3V X 60 mA or 200 >milliwatts. I am pretty sure this is not going to "break the bank." > >Yes, and if you just had to have all 8 banks use DCI, that would be 8 >times as much current. I suggest that you confine the DCI interfaces to >those banks that need them, not just for the 200 milliwatts. > >Freeze DCI has nothing to do with it. The DCI circuit has to solve for >1/2 R, R and 2R, so the average current consumption is higher than it >would be for R alone. > >One trick you can use to cut it in half is to use 100 ohm reference >resistors, and use LVDCI_DV2 (divide by two) to get 50 ohm drive. > >Now you have 100 milliwatts dissipated for the feature of using DCI in >the bank. > >If you are thinking "why did they not use 10X reference resistors? (to >lower power per bank)" the answer is very simple: the noise in a >typical system would trash a higher impedance reference system, and the >feature would have to be abandoned (or fixed) -- sound familiar?. From >the first appearance of DCI in Virtex II, it has been a solid feature in >every device since. > >DCI updating is only an issue when you cross between two banks, and even >then only with the parallel interfaces where it adds some small amount >of jitter. Freezing the updates allowed customers who did not read that >they should not go across banks to modify the bitstream, rather than >re-design their pcbs. It also allowed the highest speed interfaces to >have more timing margin (budget) which makes memory interfacing easier. > >It is always preferable to provide the customer with solutions that >involve changing bits, rather than making new boards (and them failing >to place the orders that we desire). Now we have three different DCI >options: regular (runs all the time changing +/- one trim), changes >only when reguired, and "frozen" after matching (at configuration time). > >Austin >Article: 71335
kempaj@yahoo.com (Jesse Kempa) wrote in message news:<95776079.0407140807.7cf919d1@posting.google.com>...
> "Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:<10f8r37ibfl3u8d@news.supernews.com>...
> > Pino,
> >
> > Do you have your PLL external output clock tied to the SDRAM clock pin?
> > (plus all the other sdram pins?)
> > Did you start with an example like "Thrifty" etc.?
> >
> > Ken
> >
>
> Ken is absolutely right about the PLL feeding the SDRAM clock being
> necessary. One note, though: please take a look at an example design
> specific to the board you're using (1s10). The reason I say this is
> that the clock networks on our Nios/Cyclone boards (one PLL for Nios,
> fed back into a second to drive SDRAM) are slightly different than the
> Stratix boards (only one PLL required for both an on-FPGA and external
> SDRAM clock).
>
> Also note: be sure to phase shift the external clock to SDRAM. If you
> open up the example designs and take a look at the PLL you'll see what
> I mean. This will compensate for board trace delay and should be
> adjusted if you build your own board which, obviously, will have its
> own delay.
>
> Jesse Kempa
> Altera Corp.
> jkempa at altera dot com
Jesse/Ken,
Thanks for your responses. In fact I was debating whether or not
I needed one, but both your responses definitely eliminate my thought
of not having to implement one. I agree that this is required and
will definitely help me with any board skew as well. I haven't
implemented, but will look into the example and try to use some of the
results from that for the board. Do you know what the trace-lengths
(layout) is on the board to configure the proper phase delay
parameters for the PLL for the 1s10 NIOS eval.board? Is there a
recommended number I should use?
Regards,
Pino
Article: 71336
Duane Clark <junkmail@junkmail.com> wrote in message news:<cd1coq08fu@news2.newsguy.com>...
> Steven wrote:
> > Hi,
> >
> > I now want to know whether a read or write successful or not. Can
> > someone tell me which array of variable in micron's simulation module
> > I should put in the "watch" ? The micron module is quite complicated.
> > I have problem now to get the timing right. Of course I know if I
> > cannot read the thing I write, it is wrong, problem is that maybe the
> > read has a bad timing too. So I need to see the internal content.
> >
> > I use vhdl module.
>
> That should be easy to determine from the source code. The data is
> stored in the variables Bank0-3. But if you can cosimulate with Verilog,
> I would suggest using the Verilog model. It is more up to date, though
> judging by the change log the changes are relatively minor. But a big
> advantage is that it prints out reads and writes, including the address
> and contents. Though in some situations that might be considered a
> disadvantage.
Steven,
I have a similar problem in that I have downloaded a SDRAM VHDL
module from the Micron website and have developed a master peripheral
to the Avalon Bus using SOPC Builder in Quartus. In this, I merely
connect to the SDRAM controller which is physically connected to a
128Mbit Micron SDRAM. When attempting to simulate this SOPC design
interfaced directly to the SDRAM module from Micron, I don't manage to
see any of the data that I have put in the WRITE phase, as when I do a
READ I get crap out. The verilog doesn't work well as I have not
managed to be able to interface Verilog and VHDL properly within the
same design. Definitley my lack of experience in this area to doing
it correctly. So perhaps this is a similar issue, but I am unclear
what the MICRON module is supposed to do as I don't see anything
coming out? Is the module supposed to retain information and return
it on the bus when you request it (i.e a READ)?
REgards,
Pino
Article: 71337
rickman wrote:
>
> I am writing some code to help me simplify simulation data display and I
> want to have some SLV constants in an array. These constants relate to
> defined states of a combination of signals and have names associated
> with them. To get the names to show up in the simulation, I want to use
> an enumerated type which then corresponds to the index of the constant
> array.
> Can I directly use this enumerated type as the index?
yes
> I am still a day
> or so from having some code to try. Am I barking up the wrong tree with
> this?
No, it's a good idea.
> Should I convert my enum variable to an int and use that as the
> array index?
> subtype ALUSLV is SLV07;
> subtype ALUTyp is (AD, ADC, SU, SUC, CM, CMC, AN, LOR, LXR, SR, SC,AER);
>
> type ALUstyles is array (ALUTyp) of ALUSLV := (
> "00100XX", ...
I see. Maybe like this:
-------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
entity alu_test is
end alu_test;
-------------------------------------------------------------------------------
architecture sim of alu_test is
subtype ALUSLV is std_logic_vector(7 downto 0);
type ALUTyp is (AD, ADC, SU, SUC, CM, CMC, AN, LOR, LXR, SR, SC, AER);
type ALUstyles is array (ALUTyp'left to ALUTyp'right) of ALUSLV;
constant init : ALUstyles := (AD => x"42", ADC => x"ff", others => x"00");
begin
-- sim processes
end architecture sim;
-- Mike Treseler
Article: 71338Mike Treseler wrote: > > rickman wrote: > > > > > I am writing some code to help me simplify simulation data display and I > > want to have some SLV constants in an array. These constants relate to > > defined states of a combination of signals and have names associated > > with them. To get the names to show up in the simulation, I want to use > > an enumerated type which then corresponds to the index of the constant > > array. > > Can I directly use this enumerated type as the index? > > yes > > > I am still a day > > or so from having some code to try. Am I barking up the wrong tree with > > this? > > No, it's a good idea. > > > Should I convert my enum variable to an int and use that as the > > array index? > > subtype ALUSLV is SLV07; > > subtype ALUTyp is (AD, ADC, SU, SUC, CM, CMC, AN, LOR, LXR, SR, SC,AER); > > > > type ALUstyles is array (ALUTyp) of ALUSLV := ( > > "00100XX", ... > > I see. Maybe like this: > ------------------------------------------------------------------------------- > library ieee; > use ieee.std_logic_1164.all; > entity alu_test is > end alu_test; > ------------------------------------------------------------------------------- > architecture sim of alu_test is > subtype ALUSLV is std_logic_vector(7 downto 0); > type ALUTyp is (AD, ADC, SU, SUC, CM, CMC, AN, LOR, LXR, SR, SC, AER); > type ALUstyles is array (ALUTyp'left to ALUTyp'right) of ALUSLV; > constant init : ALUstyles := (AD => x"42", ADC => x"ff", others => x"00"); > begin > -- sim processes > end architecture sim; Thanks. Shortly ago, I got word back from a friend who had borrowed my one book that actually talked about this. But your example shows me I was mixing my type def with my constant declaration. I am unusually tired tonight and am packing it in. I see I am making more errors than I am fixing :) I will hate to see what errors the simulator gives me when I try to compile tomorrow. -- 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: 71339
If it is a V2, and you only experience problems when downloading from JTAG...Keep in mind that the V2 supports partial reconfiguration. As such, the JTAG bit-banger from IMPACT doesn't invoke the global clear when re-configuring, so BRAMs will not initialize, and FFs _may_ not. I think I saw a Xilinx solution record with information on how to invoke the global initialization through JTAG manually...the Chipscope tool does this currently. Or, you can manually short the PROG pin to ground. By the way, this is documented in the V2 design guide. -S > > Dear Bob, > > > > I have a bitstream that starts always OK when loaded from configuration > > memory, and start with erratic behaviour 1 from 100 JTAG configuration > > attempts (even when JTAG configuration did not show any error during > > download). When the bitstream starts badly it behavies badly after reset > > also, only full new reconfiguration makes the system to working again. So I > > do assume it is possible that the CRC check is not sufficent in Virtex2 > > devices and that they actually do start also in case of bad download > > sometimes. > > > > You suggested this erratic behaviour of bad starting when loading from JTAG > > could be found running simulations ?! Well I really cant understand that any > > simulation models could take into account the errors that happend during > > download. ?? Or what was it what I could possible find in simulation? > > > > Antti >Article: 71340
Correction: I realise that the 54 x M4Ks and 8 x M512s memory usage must be due to sharing of memories. kommandantklink@hotmail.com (Wilhelm Klink) wrote in message news:<6011e208.0407140323.3f13a001@posting.google.com>... > After viewing the fitter RAM summary details I can say the following: > > The filter is a cascaded polyphase FIR. There are three stages, and > the first stage is a decimate by 20, so has 20 polyphase arms. Each > polyphase arm comprises of a distributed arithmetic unit. The samples > are distributed as parallel data to each polyphase arm, and then > serialised. My current interface at the input of each polyphase arm > uses 3 large registers of size nis*data_width, where nis = number of > interleaved streams = 8, and data_width = 32. 3 x 256 = 768, and > multiplying this by the number of phase arms across all cascaded > stages, this number gets very very large. Because 1FF = 1LE, this > takes up heaps of LEs, so I decided to implement these registers in > memory. In my data_width = 16 implementation (which fits in the > device) these registers are 128 bits in size, and constitute a depth > 1, width 128 memory. Clearly depth 1 memories will result in poor use > of memory resources. We have M512 = width 18, M4K = width 36, M-RAM = > width 144, so I'd expect each register to require 4 x M4Ks, or 8 x > M512s. Surprisingly, according to the fitter RAM summary, one of the > worst offending 128-bit registers used 54 x M4Ks and 8 x M512s. > > Regardless of this problem I see that it was a BAD idea to fully > parallelise the data in the input interface of each polyphase arm > (seemed the easiest way at the time though). > > Ray Andraka <ray@andraka.com> wrote in message news:<40F4532F.DBB4F364@andraka.com>... > > You'll need to provide more details as to how you set up the memory as > > well as the filter. If the sample rate is one clock per sample, then it > > is not really appropriate to use the memory because you are using only one > > location per memory (and wasting the rest). > > > > What is the ratio of your data rate to the clock? > > How many taps is your filter? > > > > > > Wilhelm Klink wrote: > > > > > I've got an FIR design that runs out of FPGA memory in an ep1s60 when > > > I set the data width to 24-bit (The design fits with a data width of > > > 16-bit). However only 13% of the total memory is used. I assume the > > > problem is that I have lots of smaller memories, and they cannot share > > > the same memory blocks (M512, M4K, M-RAM). Can anyone who has > > > experienced this problem share their strategies for dealing with this. > > > > -- > > --Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com > > > > "They that give up essential liberty to obtain a little > > temporary safety deserve neither liberty nor safety." > > -Benjamin Franklin, 1759Article: 71341
Bruce Ray wrote: > Does anybody have experience with the Altium CircuitStudio 2004 product > compared with Altera's MAX+PLUS II Baseline (or other such products) that he > could share? I forgot to add : The Altium Tolls require the free web versions of Xilinx, Altera and such to do the actual (routing-)work. The Altium tools are therefore to be regarded as layer on top of the others. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 71342
if you are writing to SDRAM module you can check value written at lines:
...
-- Write back to memory
IF Bank = "00" THEN
Bank0 (Row_index) (Col_index) := Dq_temp;
ELSIF Bank = "01" THEN
Bank1 (Row_index) (Col_index) := Dq_temp;
ELSIF Bank = "10" THEN
Bank2 (Row_index) (Col_index) := Dq_temp;
ELSIF Bank = "11" THEN
Bank3 (Row_index) (Col_index) := Dq_temp;
END IF;
....
--
and if you read you may check:
...
ELSIF Data_out_enable = '1' THEN
IF Dqm_reg0 /= "1111" THEN
-- Initialize memory
Init_mem (Bank, Row_index);
-- Load memory into buffer
IF Bank = "00" THEN
Dq_temp := Bank0 (Row_index) (Col_index);
ELSIF Bank = "01" THEN
Dq_temp := Bank1 (Row_index) (Col_index);
ELSIF Bank = "10" THEN
Dq_temp := Bank2 (Row_index) (Col_index);
ELSIF Bank = "11" THEN
Dq_temp := Bank3 (Row_index) (Col_index);
END IF;
...
in micron VHDL SDRAM simulation model (example for quad bank 64Mb Micron
model)
I've designed simple sdram controller with testbench instantiating Micron
SDRAM 32Mx2 model,
you can check it at http://www.geocities.com/mikael262/sdram.html
Mike
Article: 71343Hi all, Sorry but this question is not about logic system. I have to control the VCCO of one bank of a SPARTAN-3. I need to be able to control the drive of 3.3V, 2.5V, 1.8V, 1.5V, 1.2V to VCCO. The main control would be in the FPGA itself. I have to add an external electronic to switch between the different voltage sources. Do you have any circuit example to do a controllable voltage switch or to do an controllable DC/DC regulator. Price and dimension are very important for this design. THANKS Laurent Gauch www.amontec.comArticle: 71344
Thank you for your help. Steven Jesse Kempa wrote: > steven derrien <steven_derrien@yahoo.fr> wrote in message news:<ccu7n3$acg$1@python.ifsic.univ-rennes1.fr>... > >>Hi, >> >>Has anybody been trying to use gprof within the NIOS II IDE ? >>We have some problems regarding the profiling data that is >>send through the jtag interface directly to the IDE console window. >> >>We had a look to the documentation but there is little information >>regarding the use of the profiler with the NIOS II. >> >>It seems that, to the difference of NIOS I, the profiling data >>is sent as binary data, resulting in the following stdout trace : >> >>< Here the program standard output > >>**gmon.out data follows** >>< non readable binary data > >>nios2-terminal: exiting due to ^D on remote >> >>Does anybody knows how to solve this issue ? >> >>Thank you in advance, >> >>Steven > > > Hi Steven, > > Here are the basic steps to using GPROF in Nios II: > > (In the IDE): > 1. Add a compiler switch, "-pg", for your src code project (in the > C/C++ build area of the project properties). This is standard fare for > using GPROF regardless of processor. > 2. Add the same "-pg" switch for the compiler in your system library > project. > 3. Check the "use profiling library" checkbox in syslib properties. > > (From the SDK Shell): > 4. Run your program: Use nios2-terminal's "--gmon" switch which will > automatically capture the profiling data into a 'gmon.out' file after > your program finishes execution. This has to be done from the command > line, not the IDE. > > Note: nios2-terminal must be started with the processor in a paused > state. You can do this by opening two SDK shell windows, downloading > your program using "nios2-download <elf file>" (which downloads your > code and leaves the processor paused), then running "nios2-terminal > --gmon" in the second window, and finally running "nios2-download -g" > in the first to start execution. > > More notes: Your application must return from main() because the > profiling library's data dump is triggered by reaching atexit(). > > Also, the above notes assume that you're using the JTAG UART for > STDIO; for the conventional UART we cannot support GPROF with the > above flow just yet (this is scheduled for the next release) > > 5. Place the "gmon.out" file (generated in step 4) into the same dir > as your .elf file > 6. Run nios2-elf-gprof <elf file name> gmon.out > <output file name> > 7. Examine the output file for results. > > The above flow was actually easier than I had expected given my GPROF > experience with other processors :) However, I am sending an > enhancement request to our engineering team to make the above flow all > happen from within the IDE so that the SDK shell business isn't > necessary. > > Also, I'll see to it that this is looked at for a relevant app note > when the time comes; in addition to GPROF there is a performance > counter peripheral (which is documented in the Nios II kit) which is > useful for profiling sections of code -- such an app note will likely > describe the use of both tools. > > Jesse Kempa > Altera Corp. > jkempa at altera dot comArticle: 71345
On Thu, 15 Jul 2004 13:14:33 +0200, Amontec Team <laurent.gauch@amontecDELETEALLCAPS.com> wrote: Laurent, >Sorry but this question is not about logic system. Yes, it is. In most systems it's these "peripheral" issues that cause the most trouble... >I have to control the VCCO of one bank of a SPARTAN-3. >I need to be able to control the drive of 3.3V, 2.5V, 1.8V, 1.5V, 1.2V >to VCCO. >The main control would be in the FPGA itself. I have to add an external >electronic to switch between the different voltage sources. >Do you have any circuit example to do a controllable voltage switch or >to do an controllable DC/DC regulator. >Price and dimension are very important for this design. I suggest you trawl through Maxim, Linear Technology and all the usual power-supply suspects. For some while now, Pentium-class CPUs have had a digital output (5 bits, I think) that sends to the power supply a value indicating what Vcc(core) voltage is required. The standard CPU power regulator solutions interpret this value and change their output appropriately. They are far too powerful for your needs, but that should not be a problem - it simply means that you should be able to use smaller external components (L, C). They all provide excellent application notes and example circuits. Alternatively, if the current requirements are fairly low, you may find that the good old LM317-class regulators will do what you need. You can build a simple resistive-ladder DAC on one set of FPGA outputs, and use it to set the tail voltage for the LM317 device. There is a truly huge selection of power regulator devices available today. Their performance is much better than the older parts, they are available in tiny surface-mount packages, they are cheap (because they're used in high volume applications) and, for the switch-mode parts, they now use very high switching frequencies so that the external passive components can be quite small. It's just a question of raking through the websites until you find a part that meets all your criteria *and is freely available*. To be sure that your chosen part is available, it's often a good idea to begin your search at one of the "supermarket" distributors such as Newark/Farnell, RS, Digi-Key or whatever. Anything in their catalogues is probably a popular part with good availability. If you can cope with the flames and aggression, you might get a good response if you post on sci.electronics.design as well. If you need the design doing for you, we could probably help on a consultancy basis. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 71346
Hello ! I want to create a fifo to connect the avalon bus. I´m new to this kind of work, so it would be nice if someone of you could give me some advice. The idea is to create a fifo from which i can read using the streaming slave read transfer. Thanks GerdArticle: 71347
"Jim Lewis" <Jim@SynthWorks.com> wrote in message news:40F5EA1D.4080808@SynthWorks.com... > Peter, > As an ASIC designer, I understand the fundamental issues > with propagating signals - including reset deassertion. > I also understand VHDL quite well. > > What is not clear to me is the relationship between > my code, my reset, and Xilinx GSR after synthesis. > The following code specifies a single reset: > > process (Clk, nReset) > begin > if nReset = '0' then > Y <= '0' ; > elsif rising_edge(Clk) then > Y <= A ; > end if ; > end process ; > > What I think I am hearing is that after synthesis > targeting Xilinx technology, the reset of the register > is connected to both GSR and my nReset signal. My > nReset signal typically comes from a block which > resynchronizes it similar to how Ken Chapman recommends. > > Am I right so far? I am scanning through your Basic > VHDL document. Since I know VHDL quite well, I would > not normally read this document. I see the above > conclusions in the resulting logic equations, however, > I do not see it in written text. Is there another > document that explains this? > > Going further, how do I write VHDL that will reset a > register using GSR, but not an require external reset? > It sounds like what I am hearing (rickman) is > that I code it like above and tie the nReset > signal to '1' (or leave it unconnected?) and GSR will > remain connected to the FF after synthesis. > > Is this part right? > I am not real comfortable with this part of the process > as in ASIC synthesis, if you tie the nReset signal > inactive then it is likely to remove that function > from the register. If this is what you really do, > it is so foreign to me that I need to hear it again > and again in your documentation. > > Once I know the correct method for the above, I > too can be as smart as the other smart designers > dealing with this issue. > > Best Regards, > Jim Forgive me if I've someone's mentioned it already, but I understand that, in Virtex and later devices, synthesis tools do NOT infer the use of the GSR from the VHDL Reset signal. Instead the user's Reset is routed using general routing resources. (So, timing constraints can be applied to it.) There is of course still an issue if the external signal is truly asynchronous to the clock. The effect of the GSR on the design's flip-flops is inferred from the behavior of the Reset signal.You can change this using UCF INIT constraints (care!) The GSR is still used - at configuration time. It is an internal signal driven from the STARTUP block. You can't get rid of it (nor would you want to!) You can connect an external reset to the STARTUP block and hence drive the GSR if you want - you do this by instancing a STARTBUF component. You can also connect an internal signal to the STARTUP block to drive the GSR. If you do neither of these, the GSR is only used at configuration. I recommend Xilinx's "Simulation and Verification Guide", which discusses all this. It is available with ISE or from: http://www.xilinx.com/support/sw_manuals/xilinx6/download/ Mike Smith, Doulos Ltd. my.name@myemployer.comArticle: 71348
> > That should be easy to determine from the source code. The data is > > stored in the variables Bank0-3. But if you can cosimulate with Verilog, > > I would suggest using the Verilog model. It is more up to date, though > > judging by the change log the changes are relatively minor. But a big > > advantage is that it prints out reads and writes, including the address > > and contents. Though in some situations that might be considered a > > disadvantage. Thanks, Duane. It is quite obviously that Bank0-3 hold the memory contents. :) It is too large to put in the watch list. 64MB or more of each bank. Anyway thanks. The other tip from you is great, verilog module gives more info. Maybe micron also do not like old europe so they do not include such useful output in vhdl module. :) > >Definitley my lack of experience in this area to doing > it correctly. So perhaps this is a similar issue, but I am unclear > what the MICRON module is supposed to do as I don't see anything > coming out? Is the module supposed to retain information and return > it on the bus when you request it (i.e a READ)? > > REgards, > Pino Yes, Pino. The module works like physical module, only for simulation. It executes Read/Write command from your sdram controller, and holds the contents.Article: 71349
Of course you can, why not building a complete system just to configure the FPGA (sic). The idea of a cheap SPI flash directly connected to the FPGA is very attractive, especially in consumer application where every cent counts. Regards, Luc ___ On Wed, 14 Jul 2004 17:28:59 -0700, "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com> wrote: >Just FYI, there is an application note on this very topic that demonstrates >how to configure a Xilinx FPGA from an SPI serial Flash using a small CPLD. >The application note is written for CoolRunner-II, but practically any >Xilinx CPLD will do. > >XAPP800: Configuring Xilinx FPGAs with SPI Flash Memories Using >CoolRunner-II CPLDs >http://www.xilinx.com/bvdocs/appnotes/xapp800.pdf > >While we're on the subject, have you ever wanted to store additional >information in the configuration memory (serial numbers, Ethernet MAC IDs, >MicroBlaze code) and read it after the FPGA configures? If so, the >following application note may be of interest. > >XAPP694: Reading User Data from Configuration PROMs >http://www.xilinx.com/bvdocs/appnotes/xapp694.pdf > >The two demo designs for the Spartan-3 Starter Kit also demonstrate this >capability. >http://www.xilinx.com/products/spartan3/s3boards.htm#RF > >--------------------------------- >Steven K. Knapp >Applications Manager, Xilinx Inc. >General Products Division >Spartan-3/II/IIE FPGAs >http://www.xilinx.com/spartan3 >--------------------------------- >Spartan-3: Make it Your ASIC > > >"Ray Andraka" <ray@andraka.com> wrote in message >news:40F5AEB8.DDDC48C9@andraka.com... >> I suppose you could use an SPI flash in conjuction with a cheap up like a >PIC (some of those are less than a dollar, >> and they even have one in a SOT23 package) to undercut the cost of the >serial config ROMs. >> >> >> -- >> --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 >> >> > >
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