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, for a program such as case state is when S0=> A <= B + C; when S1=> Z <= X + Y; does it mean that 2 adders are generated, or will the synthesis recognize the adder can be shared? Or to I have to specifically write a multiplexor for the adder? Thanks! "Mike Treseler" <mike_treseler@comcast.net> wrote in message news:480fvpFhqii0U1@individual.net... > Leow Yuan Yeow wrote: >> Does resource sharing also apply for a + sign in different states? It >> appears the synthesizer doesn't like my code then. > > If you want to share an adder, > it is best to describe exactly how in your code. > > Resource sharing by synthesis requires > duplicated descriptions or a selection > that can be made either by muxing > inputs or outputs, like this: > > if op1 then > q_v := A + B; > else > q_v := C + D; > end if; > > I might duplicate a register description by mistake and > be happy about a silent band-aid from synthesis. > Or I might prefer just a warning so I can clean up my code. > Then again, I might duplicate a register just to buffer the signal > and prefer that synthesis keeps hands off. > > > -- Mike TreselerArticle: 99176
fpga_toys@yahoo.com wrote: > JJ wrote: >> That is complete nonsense. > > It's a VERY common form of TECH SPEAK used on every BBS, Chat, and IRC > system. > Then feel free to take the discussion off to some IRC system where it is appropriate. The standard in this group is English - not some sort of teenage SMS gibberish. > It doesn't matter where the poster was from, the nature and intent of > the post would make any non-english poster firmly feel unwelcome. > That's simply not true. The nature and intent of the post is to make people feel unwelcome when writing illegible contractions (the prejudice being against the style of writing rather than the writer). A very large part of that is because this group is international, with lots of non-native English speakers. For a native speaker like me, such contractions are are an eyesore and detract from the legibility of the post - for many non-native speakers, they are simply illegible. > Maybe we need to be politically correct in this global formun, at take > the top 52 languages and use one a week, or month, or year. > > John >Article: 99177
and the rest of you with half-broken keyboards: I agree with the other posts here. Your English is not "cool". It is very annoying. If you want people to help you with your homework, you better ask nicely. I dont want to answer questions from students who sound like 12 year old kids on Counter Strike chats I am not a native English speaker, its not even my second or third language. But I can still see how this is really pissing off people who are speaking proper English. Just look how many" leet speak" posts that get real answers here. If you still cant read between these lines, then you are probably too dumb for EE anyway. regards, meArticle: 99178
al99999 schrieb: > Hi, > > Can anybody please tell me what is wrong with the following code? In > post-translate simulation there are a few unexpected short pulses. > Thanks, Your logic contains functional hazards. http://en.wikipedia.org/wiki/Hazard_%28logic%29 I.e. if the input changes from 1 to 2 in 2s complement representation it will have the value 3 or 0 for a short time. 01 -> 11 -> 10 01 -> 00 -> 10 Kolja SulimmaArticle: 99179
Most (if not all) of them. This is a basic feature. Aurash leaf wrote: > Hi, > What simulation tool will enable me to read internal > signals/registers? > --- > leaf >Article: 99180
Hi John, "Not discussed was a proposal that the FPGA vendor could provide maybe subquadrant level defect bin sorting .... which could be transmitted via markings on the package, or by order selection, or even by using 4 balls on the package to specify the subquadrant." This is not a new idea, to bin them on a quadrant basis, the catch about this is more complicated than it looks. In order to bin them you need to identify the defect with much higher accuracy than normal testing, you want to know the position (that's easy ) and the nature of the defect, because not all defects will map nicely to this method, try to imagine a defect on the global routing net, this will can disable more than one quadrant, or a IO defect on a device with an IO ring (old devices) or an interruption on a long line which has cross from one quadrant to another, what about a defect DCM ? the defect map becomes quite complicated, but this is only the tip of the iceberg. In order to qualify such a part the time spent on a tester will be an x fold, not to mention the engineering effort to find out more about a particular defect ($$$) just to end up with a part which is "limping". In all this time spent on the tester you could test x times more parts (good ones) that we can sell as OK, and use engineering time to improve the coverage for testing.(not to mention the burden of managing parts with different quadrants which becomes a new part from the logistical point a view, marking packing, storing etc.) Aurash PS. I apologize for my English I'm not a native speaker/writer.Article: 99181
Hi, good question!!. I had to read the datasheet information about the frame configuration in Spartan-3... Regards, Ivan Stephane wrote: > Ivan wrote: >> Hi Jean-Baptiste, >> >> you can download a presentation about my work in: >> http://www.ii.uam.es/~igonzale/recursos/Self_Reconfigurable_Coprocessors.pdf > > > Hi Ivan, > > could you please comment, on your slide 63, how you compute the values > for the options PartialMask0,1,2 ? > > Thanks > >> >> >> I think it will be useful to understand how to develop slice-based bus >> macros :) >> >> Regards >> >> Ivan >> >> jean-baptiste wrote: >> >>> Hello Ivan, >>> >>> I would like to do a slice-based bus macro. >>> >>> But i don't know how to do. Could you help me or show me the direction? >>> >>> Jean-BaptisteArticle: 99182
For the hardware (download.bit to system.ace) nothing is special for dual ppc405. However, if you want to initialize the bram, with an elf file, connected to ppc405_1, you should do something special. My quick solution is "update your download.bit with your elf file using data2mem BEFORE you generate system.ace."Article: 99183
Thanks for all the reply! Will just leave it to synthesis then. "Mike Treseler" <mike_treseler@comcast.net> wrote in message news:488cbhFih79fU1@individual.net... > Leow Yuan Yeow wrote: >> Hi, for a program such as >> case state is >> when S0=> >> A <= B + C; >> when S1=> >> Z <= X + Y; >> does it mean that 2 adders are generated, or will the synthesis recognize >> the adder can be shared? >> Or to I have to specifically write a multiplexor for the adder? Thanks! > > There are no guarantees either way. > But it doesn't really matter. > There are not really any "adder" primitives > inside the fpga. Only gates and flops. > > All synthesis guarantees is a netlist that > simulates the same as the source code. > There is no guarantee that the RTL or > technology schematic output > will look like I expect. But it will work. > > If I code for an input mux with > one adder, I just might get two adders > and an output mux, if that better > matches the constraint settings or the whim > of the synthesis algorithm. > Or I might get just what I expect. > Or I might get something completely different. > > Luckily, synthesis does a better > job, on the average, of packing gates > into a arbitrary device than I do. > > -- Mike TreselerArticle: 99184
You don't need an extra interrupt controller if you connect two devices as you described. However, two interrupts will have different priority, and the critical interrupt (interrupt from critical interrupt port) will interrupt the external interrupt (interrupt from external interrupt port), and so if you don't write your interrupt handler code carefully, you may face some weird behaviors. Sewook WeeArticle: 99185
Hello,
We're currently working on a design running on a Virtex4 SX35. That
design uses most of the resources of the FPGA (around 80% of the slices
and 50% or the BRAMs/multipliers). We're working on the AVNET SX35 kit
with a VGA extension card and a sdram expension card.
Depending of the datafiles we send, sometimes it completly deconfigure
the FPGA ... done goes de-asserted and nothing is processing anymore
...
But that behavior is not deterministric, sometimes it can process for
one minute and then deconfigure, or sometimes it just can't even
process 1 second without crashing ... Apparently the more "heavy" is
the datastream, then faster it will crash.
Anyone would have an idea of what's going on there ?
Sylvain
Article: 99186At least you get an error. I try to create a testbench waveform and nothing happens, no error and no .tbw file. I'm using the full version of 8.1.02i, not wepack. I was just getting ready to enter a web case on this...Article: 99187
Sylvain Munaut <SomeOne@SomeDomain.com> wrote: > Hello, > > We're currently working on a design running on a Virtex4 SX35. That > design uses most of the resources of the FPGA (around 80% of the slices > and 50% or the BRAMs/multipliers). We're working on the AVNET SX35 kit > with a VGA extension card and a sdram expension card. > > Depending of the datafiles we send, sometimes it completly deconfigure > the FPGA ... done goes de-asserted and nothing is processing anymore > ... > But that behavior is not deterministric, sometimes it can process for > one minute and then deconfigure, or sometimes it just can't even > process 1 second without crashing ... Apparently the more "heavy" is > the datastream, then faster it will crash. > > Anyone would have an idea of what's going on there ? > > > Sylvain > Sounds like your design may be drawing more current than the the power supplies can provide. YOu might try monitoring the FPGA supply voltages.Article: 99188
Hello All, especially Sylvian and Goran!! As i had pointed out, we were quite new to VHDL and had a few hiccups while trying it out for the first time. We figured out the problems ourselves. The code was simply just incorrect. We've learnt to overcome that.. Thanks a lot, everyone!! -- DotNettersArticle: 99189
i use Quatus-II software for my waveform analysis is it possible there?Article: 99190
Ivan wrote: > Hi, > > good question!!. I had to read the datasheet information about the frame > configuration in Spartan-3... Actually, the explanation of these bitgen options in ISE is that it takes in consideration only the major addresses of block type 0,1,2 in hex value... but block types is not described here, and the hex chain generation is not obvious... I think you are refering to the XAPP452 ? By the way, Jean-Baptiste, you'll find dozens of resources on the web on how to create your macros. The latest one is here: http://fpl.org/RCeducation/ You create those you want with fpga_editor: add 2 slices, route them automatically, and inside slices, route with the buffers and put wires inside the LUTs, and you're done! > > Regards, > > Ivan > > > Stephane wrote: > >> Ivan wrote: >> >>> Hi Jean-Baptiste, >>> >>> you can download a presentation about my work in: >>> http://www.ii.uam.es/~igonzale/recursos/Self_Reconfigurable_Coprocessors.pdf >> >> >> >> >> Hi Ivan, >> >> could you please comment, on your slide 63, how you compute the values >> for the options PartialMask0,1,2 ? >> >> Thanks >> >>> >>> >>> I think it will be useful to understand how to develop slice-based >>> bus macros :) >>> >>> Regards >>> >>> Ivan >>> >>> jean-baptiste wrote: >>> >>>> Hello Ivan, >>>> >>>> I would like to do a slice-based bus macro. >>>> >>>> But i don't know how to do. Could you help me or show me the direction? >>>> >>>> Jean-BaptisteArticle: 99191
Does anyone here know if it is possible either using XST or Synplify Pro to flag a small number of specific nets to be ignored timing-wise in future place and route without preserving heirarchy during synthesis? Currently I'm using TIGs in my UCF file, but by the time the design has gone through XST/Synplify the nets I need to flag have dissapeared and my design is unrouteable. If I turn on heirachy preservation though, my design doubles in size and overmapps my target FPGA. Any help appreciated. Thanks.Article: 99192
Pablo Bleyer Kocik wrote:
>
> I am having a bit of trouble intercepting the adder carry in a carry
> chain with ISE using behavioral code. I am currently using two muxed
> adders (one 8-bit, one 16-bit) for the addsub module instead of the
> ideal high/low 8-bit adders with full and half carries. Any ideas on
> how to implement this in ISE?
>
I think you'll need to code dummy bits at the middle and top of
the adder to pull out the carries.
Here are some old posts with structural (Xilinx) and RTL versions:
http://groups.google.com/group/comp.lang.vhdl/msg/51a0b827ee12f69c
http://groups.google.com/group/comp.lang.vhdl/msg/15ad1c9b11079f7a
http://groups.google.com/group/comp.arch.fpga/msg/622e2173af20bb16
IIRC, using two dummy bits at the top ( '0' & copy_of_sign_bit ) makes
coding synthesizable RTL signed/unsigned carry/borrow/overflow flags
easy to implement, but quickly googling didn't turn up the post that I
recall which explained that technique.
Brian
Article: 99193On 21 Mar 2006 05:04:52 -0800, jacob.bower@gmail.com wrote: >Does anyone here know if it is possible either using XST or Synplify >Pro to flag a small number of specific nets to be ignored timing-wise >in future place and route without preserving heirarchy during >synthesis? > >Currently I'm using TIGs in my UCF file, but by the time the design has >gone through XST/Synplify the nets I need to flag have dissapeared and >my design is unrouteable. If I turn on heirachy preservation though, my >design doubles in size and overmapps my target FPGA. > >Any help appreciated. Have you tried putting the TIGs in your HDL source? Regards, AllanArticle: 99194
Hi guys, I was wondering if anyone here knows the technique that the Xilinx floating-point square-root core employs to get its results. I ask because we've got a unit that does the same job with near-identical latency and clock speed but uses far less resource (330 slices, versus Xilinx's 624 slices for single-precision accuracy). Interestingly my paper on this unit was rejected from FCCM on the grounds that "more recent developments in the field of square root calculation" have been made. Could anyone cast any light on what these are? The algorithm I used is 400 years old, but why should that make any difference if it provides the correct answer for less resource use? If anyone knows of a unit that provides pipelined single-precision square-root calculations over the full range possible inputs, I'd be interested to hear about it. Thanks for your attention, Robin BruceArticle: 99195
Hi all, I am a fresh algorithm HDL designer(mainly concern DSP algorithm HDL realize). And I am new to self-check testbench. I have get a book named "Writing Testbench", but it seems mainly about protocal and bus HDL. Is there any other resource to learn testbench skills? BTW, I use Verilog. Any suggestions will be appreciated! Best regards, DavyArticle: 99196
Ray Andraka wrote: > Sylvain Munaut <SomeOne@SomeDomain.com> wrote: > > > Hello, > > > > We're currently working on a design running on a Virtex4 SX35. That > > design uses most of the resources of the FPGA (around 80% of the slices > > and 50% or the BRAMs/multipliers). We're working on the AVNET SX35 kit > > with a VGA extension card and a sdram expension card. > > > > Depending of the datafiles we send, sometimes it completly deconfigure > > the FPGA ... done goes de-asserted and nothing is processing anymore > > ... > > But that behavior is not deterministric, sometimes it can process for > > one minute and then deconfigure, or sometimes it just can't even > > process 1 second without crashing ... Apparently the more "heavy" is > > the datastream, then faster it will crash. > > > > Anyone would have an idea of what's going on there ? > > > > > > Sylvain > > > Sounds like your design may be drawing more current than the the power > supplies can provide. YOu might try monitoring the FPGA supply voltages. I was thinking along similar lines as well. -IsaacArticle: 99197
John Bass fpga_toys@yahoo.com wrote: >With a systems guy view, I can only wonder why die level and package >level ATE is required. Why test at die level at all? Economics. Packaging costs money. Why test at package level at all? Full testing at wafer sort isn't realistic, and die damage during packaging happens. > Design for test has to be one of the most >critical requirements in the process - from die to system. It would >seem that the the ATE function should probably be redundant on the >wafer at fab, tightly integrated to the application die's IO pads -- >AND critical internal logic not visible from pads. The wafer in this >environment would have surface metalization on one edge for power and a >network interface. The ATE function on the wafer would include power >control for each die, an on wafer jtag chain, plus an on wafer gigabit >network, each bused to a set of pads on one keyed edge of the wafer. Something quite like this was tried. Some very good reasons not to do it were found, the hard way. "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." (Douglas Adams) >There is nothing special about the ATE's test interfaces, that can not >be implemented on wafer with some good test for design strategies. Power supply measurement requires an ammeter per power supply per die, or some way to switch an ammeter between measurement points, like relays. I'd love to hear your plan. Some things can't be implemented on wafers. Disk drives, relays, precision resisters, ... -- Phil HaysArticle: 99198
Aurelian Lazarut wrote: Hi Aurash > I apologize for my English I'm not a native speaker/writer. No apologies necessary with me, I've dealt with too many other cultures where it's me that has the problem. Several comments: 1) it comes down to statistically which resources will fail the most frequently. Given that the majority of the die's resources have a less global nature, I would assume (right or wrong) that the majority of the defects are less global. 2) I agree tester time is a valuable resource. I also believe there are better ways to do detailed problem issolation without that cost. Go-NoGo is one process, fault issolation another. 3) where there is a will, and good engineers, there is a way. Where the will is lacking, skill is lacking, there is always good reasons not to try. 4) If Xilinx doesn't want that business, I would certainly be happy to discuss purchasing the scrap product for a better price than crushing it.Article: 99199
Phil Hays wrote: > Why test at die level at all? Economics. Packaging costs money. > Why test at package level at all? Full testing at wafer sort isn't > realistic, and die damage during packaging happens. And for some, such a damn if you do, and damn if you don't is a purfectly good excuse to do nothing. Life isn't purfect. Finding solutions I find more valuable than finding restrctions and excuses. > Something quite like this was tried. Some very good reasons not to do > it were found, the hard way. "Human beings, who are almost unique in > having the ability to learn from the experience of others, are also > remarkable for their apparent disinclination to do so." (Douglas > Adams) One of the most remarkable forms of success, is the difficult challenges offered from failures. The cost of chipping away at this problem could be relatively small, one or two engineers for a few years adding a very small complexity addition to production die. When success materializes, the savings are substantial. > Power supply measurement requires an ammeter per power supply per die, > or some way to switch an ammeter between measurement points, like > relays. I'd love to hear your plan. It always comes down to V=IR and there are plenty of designs/products that do current sensing well, even if an external reference standard is required. Maybe one of the ATE functions is to calibrate on die standards, and pass that to the rack manager. > Some things can't be implemented on wafers. Disk drives, relays, > precision resisters, ... None of which are needed on die for self testing.
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