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
Hi Marcus, tzhe first idea here that comes to my mind is the difference for the numbering in Virtex-II compared to Virtex. In the 'old' Virtex architechture you started in the top left corner and counted down and to the right in rows and columns. Now in the V-II architecture you start in the bottom-left corner and count in a kind of x-y-diagram to the right and upwards. Check if you still have the old syntax. Previously the syntax would have been something like ...RxCy.S0. This must be now something like ...XaYb. My 2 Euro-Cent. MartinArticle: 43276
Hey, these days, I'm just happy to get my arithmetic correct ;-) "Stephan Neuhold" <stephan.neuhold@xilinx.com> wrote in message news:3CE52C82.E9F0600D@xilinx.com... > Yes of course. My mistake. I was looking at the reset signal. Add to this 2^25 > clocks at 33MHz and get 1.0666secs. So, 100ms + 1.0666secs = more than enough > time for configuration. Thanks for pointing out the mistake. > > Austin Franklin wrote: > > > "Stephan Neuhold" <stephan.neuhold@xilinx.com> wrote in message > > news:3CE4BB8F.A4A8D821@xilinx.com... > > > Yes, according to the new spec. there should be a time of 100ms provided > > before > > > your device actually needs to be active on the bus. > > > > Stephan, > > > > I believe the PCI 2.2 spec says in Table 4-6 that it is 2^25 clocks from > > RST# high to First configuration Access. And...since the PCI bus powers up > > at 33MHz, no matter what's in the slots (so it can check 66MHz capability), > > that would be 0.000_000_030 seconds times 2**25th which I believe is 1 > > second. > > > > An issue to be aware of, is that this was not spec'd in the 2.1 and earlier > > PCI spec, but...having designed quite a few Xilinx FPGA interfaces, and them > > being in thousands of production boards for some near 10 years now, I have > > never run into a problem, at least that I've heard of ;-) > > > > Austin >Article: 43277
Peter Alfke wrote: > "word of wisdom" > I think ( note the cautious wording) that you can eliminate this problem > by reorganizing your input data, effectively scrambling it, so bit 0 is > written in one BlockRAM, 1 in the next BlockRAM, etc. I am pretty sure > this works for 128 bits in 4 BlockRAMs. > I got a headache figuring it out for 3 BRAMs. > Maybe I am all wrong, but if it works, it would be really neat... > Peter Alfke, Xilinx Applications > =================================== > shparekh@yahoo.com wrote: > I don't think its possible that way. I remember coming to that conclusion for the 4-5 mapping needed for the old video DRAMs (written 32 bits wide, extracted 40 bits wide to feed into a Brooktree RAMDAC). What we did then, & what should work here, is to put the read address through a lookup table (held in an SRAM and loaded by s/w if my memory serves me right).Article: 43278
This is a multi-part message in MIME format. --------------6446B17197EA822F659997A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Stephanie, Just happened across your posting. To drive/monitor GSR, probably best to use the Startup block as what's already been suggested - although in that case you can only monitor whatever you use to drive GSR, rather than directly monitoring GSR. Although it is fairly cumbersome and not asynchronous, if you just want to poll the status of GSR from time to time, and you also happen to have (or have the ability of designing in) access to the JTAG port, you can read the output of the "Status Register", one bit of which will report the GSR status (GSR_B). See the following app notes: http://www.xilinx.com/xapp/xapp188.pdf http://www.xilinx.com/xapp/xapp151.pdf Hope that helps, -Scott S. Stephanie McBader wrote: > OK, that I understand.. But what I need is to *read* the GSR net - how can I do > that? > > Still looking out for help :) > > - Cross posted to comp.arch.fpga > > Best Regards, > > Stephanie McBader > Researcher/Design Engineer > NeuriCam S.p.A > Via S M Maddalena 12 > 38100 Trento TN, Italy > Tel: +39-0461-260552 > Fax: +39-0461-260617 > > Allan Herriman wrote: > > > [snip] > > > You can drive GSR (to reset or set every flip flop in the chip) by > > asserting the GSR input on the startup block at any time. > > > > I earlier wrote: > > > >> Hi there, > > >> > > >> Apologies if this has come up before - I have searched both newsgroups > > >> and the Xilinx support website but I have not found *exactly* what I'm > > >> looking for. > > >> > > >> Is it possible to *read* the GSR signal of a Spartan-II FPGA? The > > >> problem is that we have a system in which a controller must be > > >> implemented inside the FPGA but which does not provide any form of reset > > >> signal as an input to the FPGA logic. I have had a look at the > > >> Spartan-II datasheet and on page 19 there is a waveform describing the > > >> start-up sequence of the FPGA after programming. The GSR is evidently > > >> active high and is negated shortly after DONE goes high. I would like to > > >> be able to use the GSR value as an asynchronous reset input to the logic > > >> implemented in the FPGA.. How do I do this? > > >> > > >> I have seen numerous answers pointing to the STARTUP block, but this > > >> only has the GSR signal as an *input*! I need to read it somehow and I > > >> do not know which source to use.. > > >> > > >> Oh, we're using VHDL by the way (just thought I'd mention it even though > > >> this *is* comp.lang.vhdl) > > >> > > >> Your help would be much appreciated. > > >> > > >> Regards, > > >> > > >> Stephanie McBaderArticle: 43279
In article <3CE46EE1.79BD05C@yahoo.com>, rickman <spamgoeshere4@yahoo.com> wrote: >But the trick to it all is to define what you need in terms of >arithmetic or logic functions. Can you do that, or will you need help? I appreciate your help but I don't see the relevance of going into arithmetic or logic functions. What I really want to find out is whether or not it is feasible to use FPGA to implement a cellular system that can be programmed to make (or break) an indefinite number of connections to multiple cells on the fly. I have already read reports of FPGAs being used to implement neurons with a fixed number of connections. My neurons do not have on-off states. They send a 1-bit signal to other neurons when their input conditions are satisfied. Temporal Intelligence: http://home1.gte.net/res02khr/AI/Temporal_Intelligence.htmArticle: 43280
In article <3CE57484.D9777F38@yahoo.com>, rickman <spamgoeshere4@yahoo.com> wrote: >Interesting web site, but these prices are largely irrelevant. None of >this is open to me to purchase. Even after I register, I don't see a >way to buy. I expect these prices are for very large orders. You need to get plugged into your local distribution channels. If you need 1-10 pieces of some part that's not too expensive (e.g. <$US50?) you can generally get samples for free. If you need a few dozen, you probably have to pay, but your local distribution channels are (in my experience) pretty good guys who will try to help out. They want your business, but the guys I know are willing to go pretty far just for your goodwill. I've told people that I need ONE part, and I will NEVER need another one, and they still sample me a couple :) If your employer happens to buy lots of parts, you can probably do even better. AndrewArticle: 43281
amolitor-at@visi-dot-com.com wrote: > > In article <3CE57484.D9777F38@yahoo.com>, > rickman <spamgoeshere4@yahoo.com> wrote: > >Interesting web site, but these prices are largely irrelevant. None of > >this is open to me to purchase. Even after I register, I don't see a > >way to buy. I expect these prices are for very large orders. > > You need to get plugged into your local distribution > channels. If you need 1-10 pieces of some part that's not > too expensive (e.g. <$US50?) you can generally get samples > for free. > > If you need a few dozen, you probably have to pay, but > your local distribution channels are (in my experience) pretty > good guys who will try to help out. They want your business, > but the guys I know are willing to go pretty far just for your > goodwill. I've told people that I need ONE part, and I will > NEVER need another one, and they still sample me a couple :) > > If your employer happens to buy lots of parts, you can > probably do even better. > > Andrew For the record, Andy, he _is_ his employer. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 43282
In article <3CE59DCF.6DEF0AB@ieee.org>, Jerry Avins <jya@ieee.org> wrote: > [ re, rickman ] >For the record, Andy, he _is_ his employer. Now that I actually look at the gentleman's signature, I have a horrible suspicion he could teach me a thing or two about winkling parts outta distribution. My apologies! Didn't mean to come off condescending.Article: 43283
Ray Andraka <ray@andraka.com> wrote in message news:<3CE55872.3B8BC1F2@andraka.com>... > Russell wrote: > > > Hi all, > > > > I placed various primitives in floor-planner > > (webpack 4.2, spartan2), then grouped and > > bound it to make an RPM. I then put it back > > into the hierarchy window, so that PAR can > > place the RPM. I also saved the constraints > > to the .ucf and .mfp files. > > > > However, when i open floor-planner after PAR, > > the group (GRP0) has been placed, but all the > > primitives have been re-arranged (structure is > > lost). Has anyone got RPMs to work right? > > Yes, but not ones created in the floorplanner and then left > unplaced. That may be the case for older tools, but i think a new feature is that if you 'unplace' an RPM created graphically in the floor-planner, then PAR should place it itself. It's in webpack 4.2 help: Note: At this point, you can drag the newly created RPM from the Floorplan window to the Design Hierarchy window. When you run PAR, the RPM gets placed. If you leave the RPM in the Floorplan window, it is locked in place as seen in the Floorplan window. I've been able to create and place RPMs by modifying the .ucf file with RLOC and RLOC_ORIGIN, but still have trouble getting it to work hierarchially. In the help, it says the RLOC_ORIGIN coordinates are added to all the lower RLOCs in a macro, then all the RLOCs become LOCs. However, if i put a LOC on a macro instantiation, doesn't that do the same thing as an RLOC_ORIGIN?Article: 43284
Sweir, Thanks for this response. It was the most useful and serious response given. The other responses really did not answer the question as the original poster (and my echo) stated the inquiry. Theron Hicks sweir wrote: > Stephanie, > > I think what you are trying to ask is: > > "How do I use the internal global reset in a design that does not have an > external reset pin?" > > If so, then all you need to do is instantiate the ROC ( reset on > configuration ) component in your design. You can connect that output to > RTL that has async reset logic. > > Regards, > "Stephanie McBader" <mcbader@neuricam.com> wrote in message > news:3CE4AE8C.7016211F@neuricam.com... > > OK, that I understand.. But what I need is to *read* the GSR net - how can > I do > > that? > > > > Still looking out for help :) > > > > - Cross posted to comp.arch.fpga > > > > Best Regards, > > > > Stephanie McBader > > Researcher/Design Engineer > > NeuriCam S.p.A > > Via S M Maddalena 12 > > 38100 Trento TN, Italy > > Tel: +39-0461-260552 > > Fax: +39-0461-260617 > > > > > > Allan Herriman wrote: > > > > > [snip] > > > > > You can drive GSR (to reset or set every flip flop in the chip) by > > > asserting the GSR input on the startup block at any time. > > > > > > > I earlier wrote: > > > > > >> Hi there, > > > >> > > > >> Apologies if this has come up before - I have searched both > newsgroups > > > >> and the Xilinx support website but I have not found *exactly* what > I'm > > > >> looking for. > > > >> > > > >> Is it possible to *read* the GSR signal of a Spartan-II FPGA? The > > > >> problem is that we have a system in which a controller must be > > > >> implemented inside the FPGA but which does not provide any form of > reset > > > >> signal as an input to the FPGA logic. I have had a look at the > > > >> Spartan-II datasheet and on page 19 there is a waveform describing > the > > > >> start-up sequence of the FPGA after programming. The GSR is evidently > > > >> active high and is negated shortly after DONE goes high. I would like > to > > > >> be able to use the GSR value as an asynchronous reset input to the > logic > > > >> implemented in the FPGA.. How do I do this? > > > >> > > > >> I have seen numerous answers pointing to the STARTUP block, but this > > > >> only has the GSR signal as an *input*! I need to read it somehow and > I > > > >> do not know which source to use.. > > > >> > > > >> Oh, we're using VHDL by the way (just thought I'd mention it even > though > > > >> this *is* comp.lang.vhdl) > > > >> > > > >> Your help would be much appreciated. > > > >> > > > >> Regards, > > > >> > > > >> Stephanie McBader > > > > > >Article: 43285
Hi all, One of the Xilinx FPGA demo boards has a relaxation oscillator circuit attached to a 3000 series FPGA, where there are external RC networks attached to a pair of cross-coupled I/O blocks. Is there any reason why this would be a bad idea for a 9536XL ? The datasheet says that there is 50mV hysteresis on the inputs in the XL family but not the standard 9500s. I've cobbled a circuit together which seems to run OK, but I'm looking for any gotchas which I've overlooked. I need a not-particularly-accurate clock signal to run a state machine, and if I can get an oscillator for 'free' then that's a good thing. Thanks, Len Chisholm.Article: 43286
I'll write again what I earlier wrote to Peter. I think this is possible if the ratio of portA/portB is a root of 2. Because, the port size on brams is in power of 2. Therefore, it works in case of 128(wider port)/32(narrower port) = 4 (# of brams). i.e. scramble the 96bits in groups of 32(narrower port)/4(# of brams) = 8 bits. In my case, (portA = 96)/(portB = 32) = 3. This will not work without going through some hassle which I think will be more than using a mux or tristate bufs. Thanks all for feedback. -sanjay Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3CE5897F.94811CA@algor.co.uk>... > Peter Alfke wrote: > > > "word of wisdom" > > I think ( note the cautious wording) that you can eliminate this problem > > by reorganizing your input data, effectively scrambling it, so bit 0 is > > written in one BlockRAM, 1 in the next BlockRAM, etc. I am pretty sure > > this works for 128 bits in 4 BlockRAMs. > > I got a headache figuring it out for 3 BRAMs. > > Maybe I am all wrong, but if it works, it would be really neat... > > Peter Alfke, Xilinx Applications > > =================================== > > shparekh@yahoo.com wrote: > > > > I don't think its possible that way. I remember coming to that conclusion > for the 4-5 mapping needed for the old video DRAMs (written 32 bits wide, > extracted 40 bits wide to feed into a Brooktree RAMDAC). What we did then, & > what should work here, is to put the read address through a lookup table > (held in an SRAM and loaded by s/w if my memory serves me right).Article: 43287
Len Chisholm wrote: > > Hi all, > > One of the Xilinx FPGA demo boards has a relaxation oscillator circuit > attached to a 3000 series FPGA, where there are external RC networks > attached to a pair of cross-coupled I/O blocks. > > Is there any reason why this would be a bad idea for a 9536XL ? The > datasheet says that there is 50mV hysteresis on the inputs in the XL > family but not the standard 9500s. I've cobbled a circuit together > which seems to run OK, but I'm looking for any gotchas which I've > overlooked. > > I need a not-particularly-accurate clock signal to run a state > machine, and if I can get an oscillator for 'free' then that's a good > thing. Len, Things to watch for: Current consumption can be high, as the IP buffers spend time quasi-linear. Osc can be prone to 'frequency grabbing' due to ground noise, and Voh level can often be 'noisy'. Choose pins nearest a GND terminal, and away from any async signals. Check you have any lock-up state covered. Cross coupled Osc can have a illegal state. Three terminal ones are better behaved, but use 3 pins, not 2. For a 3 terminal OSC, best topology is NOT two inverters, but a Non-Inv followed by INV, as that makes regen feedback occur first. A Zero pin 'for free' OSC can be made using a 'foldback chain' in something like ATF1502ASVL. Because it is 100% buried, it also has good EMC characteristics, and does not use macrocells. -jgArticle: 43288
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3CE57484.D9777F38@yahoo.com>... > Matt H wrote: > > > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > news:3CE54C57.E05567F8@yahoo.com... > > > I am seeing the price of 256 Mbit SDRAM at about $20 to $25. This is > > > about 8 times what it costs for the same amount of memory on DIMMs. I > > > know that quantity makes a difference, but I can buy a single 256 MByte > > > DIMM for $22 or I can buy 1k 32 MByte SDRAM chips at $20 each. This > > > seems very excessive. > > > > > > Anyone getting better pricing on 16x16 SDRAM? > > > > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > > Hi Rick, > > Check out this community: > > http://www.dramexchange.com/default.asp > > It looks like the current price for 16x16 is about $8. Perhaps you can find > > a better price. > > Good Luck, > > Matt > > Interesting web site, but these prices are largely irrelevant. None of > this is open to me to purchase. Even after I register, I don't see a > way to buy. I expect these prices are for very large orders. > > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX Unless you are a large buyer, you are hooped. In my experience, an Asian factory can get stuff at half the price we are quoted for 10,000 quantities! Cheers, Herman http://www.AerospaceSoftware.comArticle: 43289
>I think this is possible if the ratio of portA/portB is a root of 2. >Because, the port size on brams is in power of 2. >Therefore, it works in case of 128(wider port)/32(narrower port) = 4 >(# of brams). i.e. scramble the 96bits in groups of 32(narrower >port)/4(# of brams) = 8 bits. > >In my case, (portA = 96)/(portB = 32) = 3. This will not work without >going through some hassle which I think will be more than using a mux >or tristate bufs. I don't know how this fits into your tradeoffs, but I think you can make Peter's suggestion work if you are willing to throw away 1/4 of your memory. Write 4x32 bits. Put garbage or a constant in the top word. When reading, read words 0, 1, 2, but skip over word 3. You can get that memory back if you are willing to put muxes on the input side of the RAMs. That's ugly, but it might be less ugly than putting them on the outputside - depends on how your design works out. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 43290
Hello, we have a design with a XCS30XL, which is utilized to 96%. Bad thing is, P&R takes about 30!!! minutes on a Athlon 500. The design uses a lot of TBUFs and DP-RAMS. Are there some tricks to speed up things? Some floorplanning? Timing constraints? -- MfG FalkArticle: 43291
Hal Murray wrote:
> >I think this is possible if the ratio of portA/portB is a root of 2.
> >Because, the port size on brams is in power of 2.
> >Therefore, it works in case of 128(wider port)/32(narrower port) = 4
> >(# of brams). i.e. scramble the 96bits in groups of 32(narrower
> >port)/4(# of brams) = 8 bits.
> >
> >In my case, (portA = 96)/(portB = 32) = 3. This will not work without
> >going through some hassle which I think will be more than using a mux
> >or tristate bufs.
>
> I don't know how this fits into your tradeoffs, but I think you
> can make Peter's suggestion work if you are willing to throw away
> 1/4 of your memory.
>
> Write 4x32 bits. Put garbage or a constant in the top word.
> When reading, read words 0, 1, 2, but skip over word 3.
>
In that case what we would have for the read side is:
BRAM address = read_addr / 3
BRAM select = read_addr % 3
Maybe I'm thinking of the case where the read address is random though. If
reading is always sequential then its easy.
Another approach, if there are 2 clocks available for each write, might be to use
a 64 bit wide input port:
input address 0 -> ram address = 0: words 0, 1
ram address = 1: word 2 into lower
input address 1 -> ram address = 1: word 0 into upper
ram address = 2: words 1,2
Then the pattern repeats. For each even/odd pair of input addresses the first ram
address is
3 * (input address/2)
which can be done either via a lookup table or the Virtex-2 h/w multiplier.
This approach would be less costly if the input went 128/256 bits wide since then
a 2 clock write is needed only on 1/2 or 1/4 of the incoming writes.
Note that if not enough clocks are available at the input speed you could always
use a DCM to generate a x2 clock (or x1.5 @128 bits or ...).
Article: 43292<Falk.Brunner@gmx.de> wrote: >> Spartan II >> might need to get me some FPGAs for my own board in the sort-of-near >> future. Is there any place to get them in < 10 quantity nowadays? > >Sure. > >www.nuhorizons.com > The '.de' in your signature made me believe that nuhorizons was selling the SpartanII to Europe, which is not the case. They only sell Xilinx parts to USA and Canada. OTOH seems like digikey is now selling some parts in qty=1 Josep Duran.Article: 43293
On Fri, 17 May 2002 22:11:14 -0400, "Theron Hicks (Terry)"
<hicksthe@egr.msu.edu> wrote:
>
>--------------C946C7C3EF3D55C2B62DC7EA
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Allan,
> Thanks for your response. I will comment below.
>
>Allan Herriman wrote:
>
>> On Thu, 16 May 2002 18:20:21 -0400, "Theron Hicks (Terry)"
>> <hicksthe@egr.msu.edu> wrote:
>>
>> >I would also be interested in this. I know that I can use the ISE software
>> >to set initial conditions but my device has a lot of filpflops to set/reset
>> >and connecting a "master reset" input to the GSR output would be just the
>> >trick to initializing everything. This assume that the GSR is activated at
>> >every power up event.
>>
>> You really should read the datasheet.
>
>I did. When I read it I got the impresion that the startup block uses an input
>signal to trigger the GSR input to the flipflops. It was not apparent as to how
>one can control whether the GSR acts as a set or a clear. In my case I need to
>set the initial state of condition of several dozen flipflops. While the
>constraints editor allows one to set the initial condition of flipflops, this is
>quite complex when the systen consists of several dozen flipflops. This is
>especially true if these flipflops are within a EDIF file or other similar
>device. (For example, the KCPSM microcontroller.) In this case, the designer
>may be totally ignoant as to what the flipflops are doing. An incorrect starting
>condition could result in a non-functioning design. I have designed in an
>ansychronous master reset in the design. I would like to set my design to the
>corect initial conditions via the internally generated GSR signal.
Hi Theron,
You don't need to have the reset signal in your source code (or your
EDIF) for the GSR to take effect!
GSR is *always* connected to all flip flops, and *always* driven
during configuration.
Whenever GSR is active a flip flop is forced to either 1 or a 0,
determined by the INIT property of that flip flop.
You can apply the INIT property to a flip flop directly, or you can
let the tools infer it. INIT inferrence will require coding a GSR
though. Since the xilinx flip flops don't have independently
programmable async and sync set or reset, applying a sync reset or set
to a flip flop will indirectly determine the value forced when GSR is
active.
If there is no INIT specified in the EDIF, the back end tools (map, I
think) will give it a default INIT value of 0.
Yet another way to specify the initial value is to use one of the
xilinx library elements that has a set or reset input, e.g. FDS (D
flip flop with set input). Flip flops with reset inputs go to 0 when
GSR is active, and flip flops with set inputs go to 1 when GSR is
active.
It is always good practice to have an async reset (or set) signal in
your source code so that the simulation and synthesis behaviours
match.
The better synthesis tools will realise that the async reset signal in
your source code is actually the same as GSR, and not bother to put it
in the EDIF. Even if it is in the EDIF, the back end tools (map,
again) will strip it out so that it doesn't waste general purpose
routing resources.
The synthesis tool will recognise that your reset signal is the same
as GSR by:
1. tracing it to the GSR input on a startup block, or
2. tracing it to the output of a POC block.
(NB I can't guarantee that all synthesis tools will follow these rules
exactly.)
If your fpga has an external reset pin, then I recomend connecting
that pin to the GSR input of the startup block, and also to the reset
signal in your source code.
If you don't have an external reset pin, use the POC block to provide
a reset during simulation.
You should always have either a startup block or a POC block in the
top sheet of your design.
My designs almost always have a reset pin (and a startup block) and I
find it useful to highlight that net in fpga editor. If it goes from
the pin to anything other than the startup block I have made a mistake
in my source code somewhere. (One exception would be the DLL reset
inputs, and any other fpga resources that aren't connected to the
dedicated GSR net.)
Gotcha:
If you don't specify a reset value in your source code, the default
will be 0, right?
Wrong. You have not defined the initial value, so the synthesis tool
can do whatever it wants. In particular, it can use the synchronous
set or reset input on a flip flop for logic reduction, potentially
saving a LUT. If it needed to use the set input, then the flip flop
value will be 1 after GSR.
(There's a popular synthesis tool that will sometimes do this even if
you do specify a reset value, but that's a bug. The suppliers of that
tool have asked not to be mentioned by name. Moral: gate level
functional simulation is a good thing.)
Another Gotcha:
The GSR signal is asynchronous to your clocks and has skew. Your
state machine may not get reset to the value you think it should get
because of (1) metastability problems and (2) skew.
There is no guarantee that all flip flops in your design get released
from GSR in the same clock cycle. Indeed, for fast clocks (hundreds
of MHz) it is likely that some flip flops could come out of GSR a few
clocks before others.
So, for any state machine that you really care about (often you don't)
you should add some sort of *synchronous* reset or enable signal to
make sure it starts correctly.
The GSR net is also slow, so tricks like synchronising it to the clock
with an SRL16 (which isn't affected by GSR) won't work at realistic
clock speeds.
Note that it is not easy to find these sorts of problems in
simulation.
>> GSR is the output of the startup block. GSR connects to every flip
>> flop in the chip, whether you have coded it that way or not. GSR uses
>> a dedicated routing resource that you can't see in the tools (e.g.
>> fpga editor).
>>
>
>So how does the software know what I want to use it to set or reset my
>flipflops? (Other than the constraints editor?)
Either of these should work:
1. You have applied an INIT atribute to the flip flop, either in your
source code or in the constraints file.
2. You have used a flip flop with a set or reset input (either async
or sync). You could either infer or instantiate such a component.
Here's an example of inferring a flip flop with an aysnc reset:
label : process (my_reset, clk)
begin
if my_reset = '1' then
sig <= '0'
elsif rising_edge(clk) then
if clock_enable = '1' then
sig <= something;
end if;
end if;
end process label;
Note that this flip flop will get reset when GSR is active, *even if
the my_reset signal in that code wasn't connected to GSR* (although it
should be - I'm a big hater of async design in FPGAs).
One exception to the above would be if you had tied the my_reset
signal in the code to '0', which would cause the synthesis tool to
strip it out. Don't do that.
BTW, all processes meant to infer flip flops should look something
like the above example. This should be in your VHDL coding style
guide.
I'm not sure if I fully understand the questions, but I hope this has
helped in some way.
Regards,
Allan.
Article: 43294"Brad" <hunter@dementedhampsters.com> ha scritto nel messaggio news:Xns920F884805AAFdementedhampsters@216.146.128.7... > Pcm :Automation cause an exception, exit code 80010104 > Pcm :RPC could not call the server or could not return > the results of > calling the server > Pcm :Automation caused and exception, exit code 800706BA > Pcm :The RPC server is unavailable. It also happened to me. I solved the problem by expanding the environment variables; for example if you have something like: XILINX=c:\fndtn PATH=[your path];%XILINX% Expand it as: PATH=[your path];c:\fndtn Anyway, check the Xilinx support site; I found the fix there, insert the RPC exit code as search key. P.S. Foundation 2.1i is indeed a little old, but I find it *much* better than ISE. I downgraded to it... -- LorenzoArticle: 43295
Thanks, That clarifies things a lot. Theron Allan Herriman wrote: > On Fri, 17 May 2002 22:11:14 -0400, "Theron Hicks (Terry)" > <hicksthe@egr.msu.edu> wrote: > > > > >--------------C946C7C3EF3D55C2B62DC7EA > >Content-Type: text/plain; charset=us-ascii > >Content-Transfer-Encoding: 7bit > > > >Allan, > > Thanks for your response. I will comment below. > > > >Allan Herriman wrote: > > > >> On Thu, 16 May 2002 18:20:21 -0400, "Theron Hicks (Terry)" > >> <hicksthe@egr.msu.edu> wrote: > >> > >> >I would also be interested in this. I know that I can use the ISE software > >> >to set initial conditions but my device has a lot of filpflops to set/reset > >> >and connecting a "master reset" input to the GSR output would be just the > >> >trick to initializing everything. This assume that the GSR is activated at > >> >every power up event. > >> > >> You really should read the datasheet. > > > >I did. When I read it I got the impresion that the startup block uses an input > >signal to trigger the GSR input to the flipflops. It was not apparent as to how > >one can control whether the GSR acts as a set or a clear. In my case I need to > >set the initial state of condition of several dozen flipflops. While the > >constraints editor allows one to set the initial condition of flipflops, this is > >quite complex when the systen consists of several dozen flipflops. This is > >especially true if these flipflops are within a EDIF file or other similar > >device. (For example, the KCPSM microcontroller.) In this case, the designer > >may be totally ignoant as to what the flipflops are doing. An incorrect starting > >condition could result in a non-functioning design. I have designed in an > >ansychronous master reset in the design. I would like to set my design to the > >corect initial conditions via the internally generated GSR signal. > > Hi Theron, > > You don't need to have the reset signal in your source code (or your > EDIF) for the GSR to take effect! > GSR is *always* connected to all flip flops, and *always* driven > during configuration. > > Whenever GSR is active a flip flop is forced to either 1 or a 0, > determined by the INIT property of that flip flop. > You can apply the INIT property to a flip flop directly, or you can > let the tools infer it. INIT inferrence will require coding a GSR > though. Since the xilinx flip flops don't have independently > programmable async and sync set or reset, applying a sync reset or set > to a flip flop will indirectly determine the value forced when GSR is > active. > If there is no INIT specified in the EDIF, the back end tools (map, I > think) will give it a default INIT value of 0. > > Yet another way to specify the initial value is to use one of the > xilinx library elements that has a set or reset input, e.g. FDS (D > flip flop with set input). Flip flops with reset inputs go to 0 when > GSR is active, and flip flops with set inputs go to 1 when GSR is > active. > > It is always good practice to have an async reset (or set) signal in > your source code so that the simulation and synthesis behaviours > match. > > The better synthesis tools will realise that the async reset signal in > your source code is actually the same as GSR, and not bother to put it > in the EDIF. Even if it is in the EDIF, the back end tools (map, > again) will strip it out so that it doesn't waste general purpose > routing resources. > The synthesis tool will recognise that your reset signal is the same > as GSR by: > 1. tracing it to the GSR input on a startup block, or > 2. tracing it to the output of a POC block. > > (NB I can't guarantee that all synthesis tools will follow these rules > exactly.) > > If your fpga has an external reset pin, then I recomend connecting > that pin to the GSR input of the startup block, and also to the reset > signal in your source code. > If you don't have an external reset pin, use the POC block to provide > a reset during simulation. > You should always have either a startup block or a POC block in the > top sheet of your design. > > My designs almost always have a reset pin (and a startup block) and I > find it useful to highlight that net in fpga editor. If it goes from > the pin to anything other than the startup block I have made a mistake > in my source code somewhere. (One exception would be the DLL reset > inputs, and any other fpga resources that aren't connected to the > dedicated GSR net.) > > Gotcha: > If you don't specify a reset value in your source code, the default > will be 0, right? > Wrong. You have not defined the initial value, so the synthesis tool > can do whatever it wants. In particular, it can use the synchronous > set or reset input on a flip flop for logic reduction, potentially > saving a LUT. If it needed to use the set input, then the flip flop > value will be 1 after GSR. > (There's a popular synthesis tool that will sometimes do this even if > you do specify a reset value, but that's a bug. The suppliers of that > tool have asked not to be mentioned by name. Moral: gate level > functional simulation is a good thing.) > > Another Gotcha: > The GSR signal is asynchronous to your clocks and has skew. Your > state machine may not get reset to the value you think it should get > because of (1) metastability problems and (2) skew. > There is no guarantee that all flip flops in your design get released > from GSR in the same clock cycle. Indeed, for fast clocks (hundreds > of MHz) it is likely that some flip flops could come out of GSR a few > clocks before others. > So, for any state machine that you really care about (often you don't) > you should add some sort of *synchronous* reset or enable signal to > make sure it starts correctly. > The GSR net is also slow, so tricks like synchronising it to the clock > with an SRL16 (which isn't affected by GSR) won't work at realistic > clock speeds. > Note that it is not easy to find these sorts of problems in > simulation. > > >> GSR is the output of the startup block. GSR connects to every flip > >> flop in the chip, whether you have coded it that way or not. GSR uses > >> a dedicated routing resource that you can't see in the tools (e.g. > >> fpga editor). > >> > > > >So how does the software know what I want to use it to set or reset my > >flipflops? (Other than the constraints editor?) > > Either of these should work: > 1. You have applied an INIT atribute to the flip flop, either in your > source code or in the constraints file. > 2. You have used a flip flop with a set or reset input (either async > or sync). You could either infer or instantiate such a component. > > Here's an example of inferring a flip flop with an aysnc reset: > > label : process (my_reset, clk) > begin > if my_reset = '1' then > sig <= '0' > elsif rising_edge(clk) then > if clock_enable = '1' then > sig <= something; > end if; > end if; > end process label; > > Note that this flip flop will get reset when GSR is active, *even if > the my_reset signal in that code wasn't connected to GSR* (although it > should be - I'm a big hater of async design in FPGAs). > > One exception to the above would be if you had tied the my_reset > signal in the code to '0', which would cause the synthesis tool to > strip it out. Don't do that. > > BTW, all processes meant to infer flip flops should look something > like the above example. This should be in your VHDL coding style > guide. > > I'm not sure if I fully understand the questions, but I hope this has > helped in some way. > > Regards, > Allan.Article: 43296
OK, I didn't realize you were using 1 bit models. When I dabbled with
neural nets a few years ago, the synapses carried a number to represent
analog behavior, hence there was arithmetic and logic to implement the
linear and non-linear behavior. In any event, your neuron still needs some
logical function, perhaps a sum and binary threshold. I was referring to
the model of the neuron. Mine used a fixed connection network with the
strengths of the connections determined by the learning, where you
apparently want to actually make or break the connections. You might look
at block memories as the connection matrix.
Traveler wrote:
> In article <3CE46EE1.79BD05C@yahoo.com>, rickman
> <spamgoeshere4@yahoo.com> wrote:
>
> >But the trick to it all is to define what you need in terms of
> >arithmetic or logic functions. Can you do that, or will you need help?
>
> I appreciate your help but I don't see the relevance of going into
> arithmetic or logic functions. What I really want to find out is
> whether or not it is feasible to use FPGA to implement a cellular
> system that can be programmed to make (or break) an indefinite number
> of connections to multiple cells on the fly. I have already read
> reports of FPGAs being used to implement neurons with a fixed number
> of connections. My neurons do not have on-off states. They send a
> 1-bit signal to other neurons when their input conditions are
> satisfied.
>
> Temporal Intelligence:
> http://home1.gte.net/res02khr/AI/Temporal_Intelligence.htm
--
--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: 43297
My apologies if this does indeed work in 4.2 I am using mostly 3.3sp8 because the RPMs
don't work properly in the floorplanner for 4.2 for VIrtex/VirtexE, and currently the
majority of our designs are still in Virtex/E. In 3.3, the bind and unbind works, but the
relative placement is not kept if you unplace the created macro. I think this was fixed
in 4.x.
russell wrote:
> Ray Andraka <ray@andraka.com> wrote in message news:<3CE55872.3B8BC1F2@andraka.com>...
>
> > Russell wrote:
> >
> > > Hi all,
> > >
> > > I placed various primitives in floor-planner
> > > (webpack 4.2, spartan2), then grouped and
> > > bound it to make an RPM. I then put it back
> > > into the hierarchy window, so that PAR can
> > > place the RPM. I also saved the constraints
> > > to the .ucf and .mfp files.
> > >
> > > However, when i open floor-planner after PAR,
> > > the group (GRP0) has been placed, but all the
> > > primitives have been re-arranged (structure is
> > > lost). Has anyone got RPMs to work right?
> >
> > Yes, but not ones created in the floorplanner and then left
> > unplaced.
>
> That may be the case for older tools, but i think a new
> feature is that if you 'unplace' an RPM created graphically
> in the floor-planner, then PAR should place it itself. It's
> in webpack 4.2 help:
>
> Note: At this point, you can drag the newly created RPM
> from the Floorplan window to the Design Hierarchy window.
> When you run PAR, the RPM gets placed. If you leave the RPM
> in the Floorplan window, it is locked in place as seen in
> the Floorplan window.
>
> I've been able to create and place RPMs by modifying the
> .ucf file with RLOC and RLOC_ORIGIN, but still have trouble
> getting it to work hierarchially. In the help, it says
> the RLOC_ORIGIN coordinates are added to all the lower
> RLOCs in a macro, then all the RLOCs become LOCs.
> However, if i put a LOC on a macro instantiation,
> doesn't that do the same thing as an RLOC_ORIGIN?
--
--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: 43298On Fri, 17 May 2002 05:03:11 GMT, Phil Hays <SpamPostmaster@attbi.com> wrote: > >Xilinx has a interesting idea with "EasyPath", in that they only test >the parts of a Virtex-2 that are really used in your design, and save >you some money in the process. > >http://www.xilinx.com/prs_rls/silicon_vir/0248easypath.html > >Of course, this isn't for everyone. Some of the designs may reprogram >devices to new designs frequently. See: > >http://groups.google.com/groups?hl=en&lr=&selm 010731.103308.1239036029.24248%40polybus.com > > >I would like to suggest "HardPath", in that Xilinx produces a more >completely tested version of their parts, much as the above thread >discussed. As you may or may not know, Xilinx's parts are given a >reasonable test, not a complete test. This test is good enough for most >users, however it may not be good enough for users that frequently >reprogram devices to different designs, or where the cost of failing to >correctly reprogram a device to a new design would be substantial. So >will Xilinx sell a version of their part with a more complete test? > >I know that tester time is expensive, and these parts would need to be >priced higher, and that's ok. I know that this doesn't guarantee that >there still may be a defect that has been missed that will cause a >device to fail work correctly with a new design. After all, a complete >test would take longer than practical. I'm not looking for perfection. >I'd just like better odds than what I see now. > >Anyone else interested? How about a yield sort: five categories A : Perfect B : something wrong C, D, E : something else wrong If you have a design that uses less than 75% of internal resources, you could target the B,C,D or E version at compile time, buy just those parts, and everything works. 'Something wrong' could be by quadrant, mod-4 dead resources, or something. I do lots of designs that wind up being pin limited, and use only a fraction of internal stuff. JohnArticle: 43299
Austin Lesea wrote: > Our test coverage has increased radically over the last four years, > and is still increasing. So? A complete test isn't practical. For example, look at the small switch box on the output of a CLB. Notice that each of the 8 outputs from this switch box can be programmed to one of 12 sources. The number of legal combinations is somewhat more than (12*12*12... eight times) or 12^8 or 429,981,696 different ways to program that switch box. At 25 ms per configuration load, all combinations could be verified in somewhat more than 124 days. The larger switch boxes would take rather longer. A check for interactions between switch boxes much longer still. You simply can't do a complete test, even if you wanted to. A shorter than complete test needs to make assumptions that may well be very good, but may well miss specific failures. Understand, I'm not looking for perfection. I'm looking for a better test. I'd like to buy it as an off the shelf option, if I could. I'd rather buy it from Xilinx, but if not there are other options such as a third party test house and/or do it in house. > After all, we "sell" re-configuration, so we have to test for it as > well. The cost of a failure to re-configure varies with the application, as does the odds of finding such an issue. The standard test flow is good enough for most users, as: re-programming isn't frequent, and the cost of failing a reprogramming isn't that high, and the risk of failing will vary with the application, but is fairly low. Change any two of those, however, and a more exhaustive part test becomes valuable. -- Phil Hays
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