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
Hey, I was just wondering if any of you have used/are using/have evaluated Synplicity PREMIER? it seems like an interesting compiler technology but does it do its job well? thanks in advance, kind regards, TimArticle: 104176
backhus wrote:
> None of the FPGA synthesis tools seams to support this feature, while
> every tool was capable of extracting FSMs and creating safe-FSMs if
> desired. But none seems to support State Minimization.
> Anyone knows a good reason why?
1. Such minimization is risky, rarely applicable
and can consume lots of time.
2. State machines consume a very small
percentage of fpga resources in most designs.
3. Making Fmax is often a more compelling
problem given the capacity trends in FPGAs.
-- Mike Treseler
> Or have I missed a tool? (exept design compiler, which is for ASICS)
I don't think so.
Is this reduction on by default in design compiler?
-- Mike Treseler
Article: 104177Thanks !! backhus wrote: > Hi, > you made a common mistake. Multiple assignment. > In both processes writeramb and Algorithm you assign values to signalramb. > > Your simulator detects this and resolves the conflicting values to 'X'. > Your synthesis tool will generate an error. > > Think of processes as integrated circuits. (Their enclosure is Begin and > end) There you would never tie normal (compared to tristate) outputs > together because it may lead to shortening the supply and destruction of > the ICs. > > Furthermore, If you want to enable some clocked process better write: > > if rising_edge(clk) then > if trigger = '1' then > --do something > end if; > end if; > > If you want to intialize your ram, you have to do it in another way. > For example in a single process. > > have a nice synthesis > Eilert > > ZHI schrieb: > > > > ******************************Algorithm************************************* > > Algorithm: process (trigger, clk) > > ............................................................ > > begin > > if trigger ='1' then > > if clk'event and clk='1' then > .... > > end if; > > end if; > > > > *************************************************************************************** > > Though I put three process here,I want the algorithm process to be > > executed after all the data sent into the RAMs. I put 'Trigger' as one > > of sensitivity parameters in process Algorithm. > > RAMr works normally but the RAMb always have conflict problem (For > > example ,the data 0000000000000001 saved RAMB become 000000000000000X). > > > > When I removed the codes(ramb(0)<=.....) whick is concerned with RAMb > > in the process of Algorithm. Then there is not conflict problem anymore > > in RAMb. > > > > My question is why Algorithm process effects the WriteRAMb process. > > Because I set 'Trigger=1' when the all data were sent into RAMs.Then > > the process Algorithm is activated.Article: 104178
bh wrote: > Well this is a long shot, but is it possible that one is fixed at Full > Duplex (no-negotiate) while the other is trying to negotiate and falls-back to > half-duplex? I have tried with both ends forced t full-duplex, just incase. and made a new crossover cable too, just incase. I had some good success with turning off the internal ac-coupling caps as someone mentioned, and things look more sane. For small packets ~65-128 bytes long I get good transmission with maybe 1-2% packet loss, larger packets seem to be a problem however. With an idle link I see the /K28.5/D16.2/ idle pattern fine, but sometimes the /D16.2/ is corrupt, and gives a "notintable" error from the MGT, always with what seems to be the same pattern. I need to get Synplicity's Identify_debugger to play nicely tomorrow with a nice long sample memory to check how regular this is happening. The external logic analyser I have access to currently doesn't have the depth when running at a decent speed. Maybe a possible issue with the MGT itself? I can move to another one i think and test that. -- /\/\arc Kelly ..Just your average physicist trying to get by in a world full of normal people...Article: 104179
backhus wrote: > Hi everybody, > > after a long discussion about State Minimisation with ISE > > http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/35d66d3783725017/d282151c06a511ae?lnk=raot&hl=de#d282151c06a511ae > > > I was looking for other tools supporting this feature. > The result was disappointing. > None of the FPGA synthesis tools seams to support this feature, while > every tool was capable of extracting FSMs and creating safe-FSMs if > desired. But none seems to support State Minimization. > > > Anyone knows a good reason why? > Or have I missed a tool? (exept design compiler, which is for ASICS) You need to define what/where you expect Minimize ?. Johnathon makes a good point, that state merge minimize (which seems to be your main focus?) is not a common problem. I can see risks, and we already suffer from tools that are 'too clever by half' - if the tools missed that the merge states were being used somewhere, you would have a nasty bug. What about a time-keeper state : one that appears empty/redundant to a logic parser, but is actually needed for timing - should we let the tools loose on those ? There are also many different State Minimize yardsticks : This week, I have a state engine that uses a Johnson counter, and found (by the eyeball inspection optimize method) that extending (rather than merge) the state decode, reduced the decode logic overhead => higher packing density. In this case, that mattered - more often, it is a don't care. Johnson was also better overall packing, than Gray or Binary, but I'm not sure I'd expect the tools to be able to make those calls. I suppose a tool that took a state engine, and spawned a huge number of possible solutions and then reported the six best, could be usefull ? -jgArticle: 104180
Jonathan Bromley wrote: > On 20 Jun 2006 05:56:06 -0700, "Andy" <jonesandy@comcast.net> wrote: > >is not an easy task (read: extends run-time). Unless you're doing guided P/R, synthesis run-time is typically a smaller fraction ( < 20% ? ) of total build time for the bitstream. And to my way of thinking, if the synth tool implements state minimization properly, it would be a user selectable option for each FSM, just as XST currently allows selection of encoding algorithm for each FSM. So the effort need be expended only on those FSMs that benefit from it. > been helpful. The kind of "sequence recogniser" state machine > that was used as an example isn't very realistic, is it? I thought it was very plausible as a _simplified_ example. Sequence recognizers are important in all sorts of coding schemes that are used today (MPEG/JPEG etc.), which contain specific markers delineating starts of blocks. I took a good hard look at Eilert's example, and could not come up with a circuit that beats the 3 LUT + 3 FF solution (there's a challenge). And the technique is certainly not limited to sequence recognizers, but to any sort of FSM which may have equivalent states. If state collapsing provides the smallest/fastest circuit in some cases, I think it would be very nice to have it as a synthesis option. Would anyone _not_ want it as an option? Further ISE results: I stood Eilert's LSB-first circuit on its head, and tried the MSB-first version. Before state reduction: 15 states: Auto and Sequential (produced same netlist): FFs / LUTs / est Fmax: 4 / 9 / 400 MHz (2 LUTs in front of each FF, and 1 LUT decoding 2 FFs) Compact: FFs / LUTs / est Fmax: 4 / 5 / 536 MHz (1 LUT in front of each FF, and 1 LUT decoding all 4 FFs) After state reduction: 8 states: Auto: FFs / LUTs / est Fmax: 3 / 3 / 553 MHz ( 1 LUT in front of 2 FFs, direct input to 3rd FF, and Compact / Sequential / Gray: FFs / LUTs / est Fmax: 3 / 4 (!) / 553 MHz (1 LUT in front of each FF, and 1 LUT decoding all 3 FFs) The reason posted these ( and I hope they haven't spoiled any of Eilert's lab exercises) was because I was surprised to see the "Auto" encoding produce better results than the "Compact" encoding. Know your tools! Best Regards, JohnArticle: 104181
JustJohn wrote:
> If state collapsing provides the smallest/fastest circuit in some
> cases, I think it would be very nice to have it as a synthesis option.
> Would anyone _not_ want it as an option?
The option would be fine.
Paying $10,000 for it wouldn't be.
-- Mike Treseler
Article: 104182JustJohn wrote: <snip> > If state collapsing provides the smallest/fastest circuit in some > cases, I think it would be very nice to have it as a synthesis option. > Would anyone _not_ want it as an option? That would be usefull, but it should also have the ability to include some defined state-decode in the 'optimise bucket', so you get smallest size/best speed of the machine, and critical decode paths. In my most recent FSM, I coded a johnson ctr ( not an option in XST ?), and there were decode savings on the optional mapping of the unused/unmapped states. What could be usefull, is a tool that simply reports wasted/merge-able states. > > Further ISE results: > I stood Eilert's LSB-first circuit on its head, and tried the MSB-first > version. > > Before state reduction: 15 states: > Auto and Sequential (produced same netlist): > FFs / LUTs / est Fmax: 4 / 9 / 400 MHz > (2 LUTs in front of each FF, and 1 LUT decoding 2 FFs) > Compact: > FFs / LUTs / est Fmax: 4 / 5 / 536 MHz > (1 LUT in front of each FF, and 1 LUT decoding all 4 FFs) > > After state reduction: 8 states: > Auto: > FFs / LUTs / est Fmax: 3 / 3 / 553 MHz > ( 1 LUT in front of 2 FFs, direct input to 3rd FF, and > Compact / Sequential / Gray: > FFs / LUTs / est Fmax: 3 / 4 (!) / 553 MHz > (1 LUT in front of each FF, and 1 LUT decoding all 3 FFs) > > The reason posted these ( and I hope they haven't spoiled any of > Eilert's lab exercises) was because I was surprised to see the "Auto" > encoding produce better results than the "Compact" encoding. Know your > tools! In one case, but not the other ? -jgArticle: 104183
GaLaKtIkUs=99 wrote: > Rewrite the whole libraries, which model Xilinx primitives for all > Xilinx FPGA/CPLD families and all speed grades? Why not just rewrite the ones you need, instead of ALL of them?Article: 104184
Dear Student, Perhaps you may inform us of the Altera board of which you speak. The model number of the board would help. <roiavidan@gmail.com> wrote in message news:1147616918.488954.315130@y43g2000cwc.googlegroups.com... > First of all - thanks alot for all of your quick replies. > I will try to ask my question in a more precise manner. > > I need to build a piece of hardware ( I already wrote most of it in > vhdl and as schematic designs ) that will manipulate a large amount of > data - data that i believe cannot fit on-chip with the design itself. > thus i would like to use one of the on-board memories available to me. > i believe the cyclone board comes with SRAM (or SDRAM), and with this > board i also have a 32mb flash card. > > what i'd like to know is how to use a simple ready-made interface for > either one of these memories ( i don't care which one ). i do not want > to write my own interface. > i want the ability to read and write to memory without needing to know > how the "memory internals" work. > > is there such a solution for me? > > many thanks again!! > > Roi >Article: 104185
Jim Granville wrote: > JustJohn wrote: > > The reason posted these ( and I hope they haven't spoiled any of > > Eilert's lab exercises) was because I was surprised to see the "Auto" > > encoding produce better results than the "Compact" encoding. Know your > > tools! > > In one case, but not the other ? Yes - for the LSB first "10-15 detector" FSM w/ pre-encoding state reduction, Compact encoding gave 3 LUTs Auto encoding gave 4 LUTs With the MSB first, Compact encoding gave 4 LUTs Auto encoding gave 3 LUTs I don't mind that the results are not exactly as advertised, as long as I know to "expect the unexpected". JohnArticle: 104186
Hello Antti, Thank you for the nice comments, and we'll look forward to seeing you on our support forums. David PellerinArticle: 104187
Hi all, We want to implement a design in a spartan - 3. and select a device (in terms of system gates) at the initial stage of the project. Is there any method for this.Article: 104188
Thanks for your response!
the used code (VHDL) is not mine, it is the I²C-core from opencores.org
and the initial value is set in the way you explained (and not somewhere
else):
if (nReset = '0') then
c_state <= idle;
elsif (clk'event and clk = '1') then
....
The state machines are implemented correctly as recommended in the Quartus
Help.
I think it works because of the initial reset, but I don't understand the
difference to prior Quartus versions.
Is it synthesized in the same way and this Critical Warning is only a new
information and not really critical???
MB
"KJ" <Kevin.Jennings@Unisys.com> schrieb im Newsbeitrag
news:1150822465.041775.245070@i40g2000cwc.googlegroups.com...
>
> Manfred Balik wrote:
>
>> This I/O cells are the states of the state machines. How can the state
>> machines be in the right state if the power-up level is not correct
>> initialized ???
>
> If you've properly coded your state machine, then they should be put
> into the proper state by some form of reset signal that occurs, not as
> a result of some 'power-up' default.
>
>> The new compilation works anyway!!!
>
> Either your state machine is coded properly but there is an extraneous
> 'initial' value (see code snip below) or you're just getting
> lucky....for now. If it's the 'lucky' option, then your luck will run
> out on you, investigate the code.
>> Can someone explain it to me???
>>
> Possible source of the problem (assuming VHDL source)
>
> -- In your signal declarations (or variables depending on your coding
> style) is something like this...
>
> type t_The_States is (Idle, Do_Something, Do_Something_Else, Done);
> signal Current_State: t_The_States := Idle; <--- This would be an
> initialization that would get ignored if you have it.
>
> Further down into the code you probably have something like this...
>
> if (Reset = '1') then <- Better have this and reset better occur
> after power up
> Current_State <= Idle; <- If you want to get into this state after
> power up
> else
> case Current_State is
> .....bla, bla, bla
> end case;
> end if;
>
> KJ
>
Article: 104189Guess the number of registers or flip-flops in your design ( you get 2 ffs per slice) and guess the amount of RAM (you get 18 K bits per BlockRAM) and guess the number of I/O. Gate count is not a meaningful number in FPGAs. That should give you a starting point. Peter Alfke, Xilinx Applications ======================= Pravin G wrote: > Hi all, > > We want to implement a design in a spartan - 3. and select a device (in terms of system gates) at the initial stage of the project. > > Is there any method for this.Article: 104190
On 20 Jun 2006 23:18:06 -0700, "Peter Alfke" <alfke@sbcglobal.net> wrote: >Guess the number of registers or flip-flops in your design ( you get 2 >ffs per slice) >and guess the amount of RAM (you get 18 K bits per BlockRAM) >and guess the number of I/O. >Gate count is not a meaningful number in FPGAs. > >That should give you a starting point. And, if your desing will work with a clock of more than, say, 50 MHz, double or triple your stimates to take into account possible routing and FF duplication problems. BTW, double or triple it anyway. You will feel happier, with not much cost increase. Bets regards, ZaraArticle: 104191
Error from vcom: Attribute "event" requires a static signal prefix.
Xst handles this very nice..
Are there any tricks around this, except the obvious "remove the
procedure"...
-----vhdl code below----
process(INP,GRES,CPUnRES)
PROCEDURE TRIGRD
(
reg : INTEGER range 0 to 255;
bt : INTEGER range 0 to 15;
neg : boolean
)
IS
--Triggers the read bit using the input bit as source
BEGIN
if(neg=false) then
if(GRES='1' or CPUnRES='0') then
readbits(reg*8+bt)<='0';
elsif(INP(reg*8+bt)'event and INP(reg*8+bt)='1') then
readbits(reg*8+bt)<='1'; --set if clocked high
end if;
elsif(neg=true) then
if(GRES='1' or CPUnRES='0') then
readbits(reg*8+bt)<='0';
elsif(INP(reg*8+bt)'event and INP(reg*8+bt)='0') then
readbits(reg*8+bt)<='1'; --set if clocked low
end if;
end if;
END TRIGRD;
...
TRIGRD(0,1,false);
....
end process;
Article: 104192Hi everybody, thanks to everyone for their contributions. Some of you mentioned that state minimization rarely improves most FSMs, except the mentioned decision-tree example type. I made the same experiences and agree to that. The surprising point for me was that state expansion also is a method to get faster and/or smaller results. Some mentioned a large increase of synthesis runtime due to a state minimization algorithm. I don't think so. My experience with dc is that it's done almost instantly (on a 400 MHz Sparc) and most of the time is spent for writing messages to the screen. In fact, after extracting the FSM into a state table the algorithm just needs to sort that table, look for equivalent outputs and next states to be eliminated and rearrange the next-state entries to the remaining collapsed state. I think synthesis tools already have much more complex algorithms working than this one. State expansion could be much more complicated, since it needs a area/timing estimation to calculate the benefits of creating aditional states. Jim feared that during state minimization time keeper or wait states could be eliminated. Definitely not. The next-state of a wait state is never equal to any other state, so it can't be eliminated. About how and when such an algorithm should be applied... Well, like most special features of an EDA tool it should have a control flag, either by command line or GUI. In dc, to answer Mikes question, every step is performed by a separate command. Like this: --- compile -map_effort medium <- performs an initial optimization extract <- finds the FSM set_fsm_minimize true <- enables the state minimization compile -map_effort medium <- optimize again --- Best regards EilertArticle: 104193
An Altera application note (AN-349) recommends placing certain outputs on column pins and others on row pins. My question is: which pins of the Stratix device are column and which are row pins? Is there a document that includes this info? I assume that the assignment is fixed and given by architecture, not dynamically? Thanks for advices, Roland.Article: 104194
Hi Austin, besides everything concerning the security gain of an encrypted bitstream I have a different question. Xilinx offers a similar feature too in its Virtex4 (and 5?) FPGAs. Now, that some silicon already is used up by the AES algorithm, wouldn't it be nice to make it accessible to the custumer? Just the Keyscheduler and the round function, not the key memory. Would be a nice feature for some custumers, but (nearly) no drawback for all others. Best regards EilertArticle: 104195
"Zara" <dlm0-hbge@dea.spamcon.org> wrote in message news:veqh92hat9gj4uahkm8rd3jlah8nllpf1o@4ax.com... > On 20 Jun 2006 23:18:06 -0700, "Peter Alfke" <alfke@sbcglobal.net> > wrote: > >>Guess the number of registers or flip-flops in your design ( you get 2 >>ffs per slice) >>and guess the amount of RAM (you get 18 K bits per BlockRAM) >>and guess the number of I/O. >>Gate count is not a meaningful number in FPGAs. >> >>That should give you a starting point. > And, if your desing will work with a clock of more than, say, 50 MHz, > double or triple your stimates to take into account possible routing > and FF duplication problems. > > BTW, double or triple it anyway. You will feel happier, with not much > cost increase. > > Bets regards, > > Zara I can suggest three alternative selection strategies. Sadly, two are rubbish! 1) Start with your budget. Fit the biggest part you can afford. 2) Use the smallest part available. You'll find that necessity becomes the mother of invention. 3) Ask your FAE about your specific design. Cheers, Syms. :-) Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.phpArticle: 104196
On 21 Jun 2006 10:53:51 +0200, "Symon" <symon_brewer@hotmail.com> wrote: >"Zara" <dlm0-hbge@dea.spamcon.org> wrote in message >news:veqh92hat9gj4uahkm8rd3jlah8nllpf1o@4ax.com... >> On 20 Jun 2006 23:18:06 -0700, "Peter Alfke" <alfke@sbcglobal.net> >> wrote: >> >>>Guess the number of registers or flip-flops in your design ( you get 2 >>>ffs per slice) <...> >> >> BTW, double or triple it anyway. You will feel happier, with not much >> cost increase. >> >I can suggest three alternative selection strategies. Sadly, two are >rubbish! > >1) Start with your budget. Fit the biggest part you can afford. Nice one. probably the best. >2) Use the smallest part available. You'll find that necessity becomes the >mother of invention. And budget grows exponentially, due to hours lost in redesigning and using obscure device-dependent resources to get the thing to work. Or incrementing the number of tasks done by SW. You know, SW engineers tend to be untreatable. >3) Ask your FAE about your specific design. If you have one. If he knows the modern components available. If it is not yourself. Cheers, ZaraArticle: 104197
It's generally a good idea to understand the source of a 'critical' warning...actually not a bad practice to understand the source of 'not so' critical warnings too. You didn't say whether the place in the code where the signal is actually declared has an initial value assigned to it. Look for the place where the signal is declared and see if it looks anything like... signal Current_State: t_The_States := Idle; <--- This would be an initialization that would get ignored if you have it. Usually, initial values of any sort are not synthesizable (i.e. each of the following statements) signal slv: std_logic_vector(7 downto 0) := "10101010"; signal Counter: natural range 0 to 255 := 200; If you do have initial value assignments like these, then the reason for the warning is because this is the type of code where simulation results will differ from actual results. The above statements are all legal VHDL and any simulator will initialize the signals exactly the way they are defined to be at t=0. If the targetted device does not support power up default values (and generally they don't other than some devices do guarantee to power up all flops at '0') than the behaviour of the real part will differ from that in simulation. Whether or not you simulate, keep in mind that someone down the line who inherits your code might so what you should do is purge any and all initial value declarations in your code that are not synthesizable to your target device and do not conform to what the device actually does. Even if the initial values is '0', that initial value assignment can likely be purged from the code even though technically they are synthesizable when targetting a device that guarantees flops to initialize to '0'. In that particular situation I wouldn't expect that you should get any warning since the part does in fact grant you your wish of an initial value. What it also does though is limit your code to devices that do give you that guarantee. There are occasional times when an initial value assignment is actually needed but not too often. So if your design doesn't reeeeeally need the initial value then best just to purge it and not limit the universe of possible targetted devices without good reason KJArticle: 104198
Hi there guys, I'm after some help with creating a VHDL testbench model for Root Complex Emulation. My system has an FPGA with one PCIe Endpoint that is connected to a uP that has in-built Root Complex. To test the FPGA i obviously need to drive the differential inputs at the PCIe interface (via 8b/10b). Although this sounds like a mammoth task, my PCIe interface will support only a small subset of features e.g. - only 1 lane - only one Traffic Class - only one virtual channel (hence no arbitration) - no MSI support - no INTx - no Advanced error reporting - always await ack before proceeding with new request I "don't think" i'll have problems generating/sequencing the TLP's but i am having trouble understanding/getting info about what happens directly after power-up (...called enumeration !?) with regards the set-up sequencing - e.g. negotiation of lane widths and frequency of operation, training the link etc - basically everything that needs to be done before the link becomes useable. A N Y help/tips/pointers either with this Q or just in general regarding PCIe would be greatly appreciated.Article: 104199
>After the long and intriguing thread on state minimisation, I had >been thinking about various state machines - trivial and not so >trivial - that I've designed over the past few years; and I can't >think of even one where automatic state merging would have >been helpful. The kind of "sequence recogniser" state machine >that was used as an example isn't very realistic, is it? It's often useful to think of large state machines as software. They are just easy cases of microcode, usually implemented in ROMs. If you are just over a power-of-two boundary, saving a few states can get you into the next smallest size ROM. If you are working with an existing design, sometimes it's the difference between fit and won't-fit. I suspect that going from 17 to 15 states might simplify things enough to be very interesting in some cases. My vote would be for a utility to process a state machine and tell me about the redundant states so I could fixup the source code by hand. Years ago, I wrote a hack to scan some microcode and check for redundant states. I forget the context. Maybe a friend was out of space and desperate for a few more words. It might have just been a hack. I think it saved a dozen out of 4K. -- 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.
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