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
States A2 and A3 will function exactly the same, but A1 will be different. If you monitered State_A'transaction in a simulator you'd get a response on every clock cycle with A1, but only when A='1' for A2 and 3. It may mean the difference between synthesizing a register with an enable (in the case of A2 and A3) and without (A1). the null statement can be very useful for specifically ignoring certain cases.Article: 123451
Jon, In my experiance I have found that the answer to your question is....it depends :) The total number of PCB layers is dependent on all components, voltages, and signaling types utilized on the board. If you have strict requirements on isolation and noise then the count goes up. Looking at it from a signal layer count for supporting of the FPGA only, I have found that n/2 is a good approximation, where n is the number of rows to get to that center point of the package. I guess you could say the total number of rows for the package divided by 4. That is most likely your minimum number of signal planes. Again, the whole thing is academic, because each design is different. If you have not utilized 100% of the I/O, then your count might be lower. If you have used 50% of the I/O, but it is all in a few banks, then you will need to use more layers than if the I/O had been spread over the entire package. Finally, look at the requirements for your other components. Analog devices usually have different voltages, or multiple ground requirements that can greatly influence your stackup. Good luck, vt2001cpe On Aug 28, 9:23 am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Hi > > I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there a > general rule of how many layers the pcb will need to route out all the > pins? > > Cheers > > JonArticle: 123452
I installed the ISE service pack 2, and the error message became more specific: ERROR:Xst:2744 - "C:/Dokumente und Einstellungen/A/Eigene Dateien/FPGA/ fixpt-test/vhdl200x/fixed_pkg_c.vhdl" line 1026: alias of a function is not supported. ERROR:Xst:2683 - Unexpected error found while building hierarchy. So I commented out the function aliases cleaned up the project files (otherwise I would get "ERROR:HDLParsers:333 - Binary file "xst/ ieee_proposed/sub00/vhpl02" is corrupted. Recompile unit fixed_pkg.fixed_pkg."), and everything compiles just fine. Only division does not work: ERROR:Xst:769 - "C:/Dokumente und Einstellungen/A/Eigene Dateien/FPGA/ fixpt-test/vhdl200x/fixed_pkg_c.vhdl" line 2599: Operator <INVALID OPERATOR> must have constant operands or first operand must be power of 2 AndreasArticle: 123453
On 28 Aug., 16:09, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> wrote: > > Perhaps because they are too lazy to implement features which > customers can easily be led to believe are frills? I would say that they do not question decisions that were made by synopsys 20 years ago. > E.g. Jonathan > Bromley posted on 2007 March 5th: Hmm. I just have to counter that post here. > [..] The majority of > hardware platforms do not offer reliable power-up > initialisation of internal state. True. But the vast majority of design starts are on platforms that do support it. > Consequently it is appropriate > to code explicitly some reset behaviour. At extra hardware cost on my platform. > For exactly this > reason, the hardware-oriented data types in VHDL (std_logic, > etc) have a specific undefined value as the leftmost value > of their value-set, so that initialisation oversights are > more likely to be detected. So, when I explicitly assign an initial value of '1' and then start synthesis for a platform that supports initial values the synthesis tool should synthesize to an initial value of '0'? How does that detect initialization oversight? It is an implementation error. Plain and simple. Leaving the initial value unassigned makes formal verification a PITA. > This issue is > one of those things that hardware designers are required > to be aware of, Surely the OP meant "ASIC designres". > and failure to attend to it is usually a good > identifying mark of a beginner, or a dyed-in-the-wool > programmer assuming that hardware design is easy. Well it isn't. But it could if tools would catch up. We spend easily 25% of the design time of the last project debugging the tools. (Deciphering such great synthesis guidelines as the statement that arrays should not be used. Instead std_logic_vector should be used. But that is an array. Hmm.) Kolja SulimmaArticle: 123454
eli.billauer@gmail.com wrote:
> Now to my suggestion: The problem is that paths which end up in the
> flip-flops' CE pin are taken for multi-cycle paths.
I don't follow this.
A clock enable is just a synchronous input.
Which tool automatically constrains timing for these?
-- Mike Treseler
Article: 123455Weng Tianxiang wrote: > I open a new topics from previous one to try to stir another round to > introduce a new keyword 'orif'. The old bait and switch. I've been trolled again. -- Mike TreselerArticle: 123456
On Tue, 28 Aug 2007 08:23:56 -0500, "maxascent" <maxascent@yahoo.co.uk> wrote: > >Hi > >I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there a >general rule of how many layers the pcb will need to route out all the >pins? > >Cheers > >Jon We've done Spartan3 FG456 chips on 6 layers, so you'll probably need 8 or 10. Start sketching! JohnArticle: 123457
Thanks for all the info. I think I may be able to get away with using 8 as not all of the banks are fully utilised. JonArticle: 123458
ajith.thamara@gmail.com wrote: > 1. So when i try doing this the program is not completely get written > and gets hanged in between. But when i generated raw bit files (using > - b option in bitgen) i am able to transfer the whole content , but > after downloading, the system is not functioning as expected ( no > change in the display). > The other thing is that the size of original .bit file is 158kB, > and .rbt file is 1356kB - so what makes the .rbt fle so big. Open it in a text editor and you'll see. The .rbt is a text file containing the ASCII characters '0' and '1' for all the bits. This you cannot send through ICAP, it is meant to be used to do very simple bit-banging with a uC (you just read in the rbt byte by byte and set an IO according to the byte to toggle the external serial data input). For use with ICAP, you have to use the bit-file, not the rbt. If you transfer the rbt, the configuration logic detects that this is not a valid bitstream, and that might be what hangs your program (not sure, I've never tried sending an invalid bitstream). If you do send a valid bitstream (the .bit-file) and it doesn't change the system's behaviour, it could be several things: - The new partial bitstream isn't really different from the original - It's not a valid partial bitstream (wrong startup clock, CRC incorrect...) Have you tried loading the partial bitstream with iMPACT over JTAG instead of using ICAP? If it doesn't work then, there's something wrong with the bitstream. > 2. I tried downloading .bin file (generated using - g binary : yes > option in bitgen) again the whole data is not getting transfered but > gets stuck up in between. but the size of this file is only 157kB with > header removed. Hmm, the bin should be loaded completely... the only thing I can think of why it would not be is that the configuration logic requires some clock cycles after the configuration data to empty it's internal pipeline. At least when I'm loading a bitstream via the external interface, I always have to generate several clock cycles after the configuration data before the done pin goes high. Not sure, but maybe it is the same with ICAP. HTH, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 123459
> I will have to get a scope, but for the time being ... the data bus coming
> in
> does not change state, yet some bits are registered at the opposite
> state for 1 clock cycle (@ 60 MHz).
So this seems critical ... during a period where data is supposed to be
quiesent,
you are detecting spurious false states. So this sounds not like a timing
problem,
but some "noise problem"/power supply/misc gremlin problem.
To answer your original question, I have been using Xilinx devices for 10
years,
and before they are released for general use, they are pretty bullet proof.
However, there are lots of pwb/power supply device interconnect issues that
can cause related problems.
Here are some things to do :
[1] Take a look at the input signal with a scope .... make sure HI/LO
voltage
levels match what FPGA expects. [Look at the .pad file in synthesis
directory.
This defines the electrical interface for the input signal. Adjust the
trigger, and
see if there are spurious events on signal input.
[2] Verify the Bank Voltage on the device is correct.
[3] Are single clock events permissible? If not, use something like the
following
snippet as a "debug trigger".
wire debug_trigger = signal[2] & ~signal[1] & signal[0] | ~signal[2] &
signal[1] & ~signal[0];
always @ (posedge clk)
begin
signal_q <= {signal[1:0], input };
end
Then bring the debug_trigger to an FPGA output which can be monitored
with a test point. Use this as a trigger to oscope and look at the actual
input signal on its pin at FPGA. A few clocks before you will see the
offending
event.
--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.
Colorado Based Xilinx Consultant
email : jretta@rtc-inc.com
web : www.rtc-inc.com
"Analog_Guy" <analog_guy@hotmail.com> wrote in message
news:1188309687.062604.84880@i13g2000prf.googlegroups.com...
> Thank you for your responses.
>
> On Aug 28, 9:07 am, Gabor <ga...@alacron.com> wrote:
>>
>> If you suspect ringing or glitches I'd look with a scope instead
>> of the logic analyzer. When you say the bus is stable, do you mean
>> a bit that hasn't changed state is registered at the opposite state?
>>
> I will have to get a scope, but for the time being ... the data bus
> coming in
> does not change state, yet some bits are registered at the opposite
> state
> for 1 clock cycle (@ 60 MHz).
>
>> What about hold time? Are the input registers using the built-in
>> delay path? What does the post P&R timing report show for hold
>> time requirement on these inputs?
> The data sheet report shows that the setup times for all data bus bits
> are 1.958 ns, and
> the hold times are -1.006 ns.
>
>>
>> All Virtex registers are fast in terms of capturing glitches. Another
>> thing to look at with a scope is the rise / fall time of the input
>> signal. Logic analyzers tend to mask this. Maybe you don't have
>> as much setup time as you think if the Virtex and logic analyzer
>> don't use the same threshold levels.
>>
>> HTH,
>> Gabor
> I will have to instrument a scope to look at the rise times ... thank
> you.
>
Article: 123460On Aug 27, 9:11 pm, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi, > I open a new topics from previous one to try to stir another round to > introduce a new keyword 'orif'. > > > > > One thing I miss a lot is 'orif' keyword compared to 'elsif'. > > > > 'orif' introduces a group of conditions that are mutually exclusive. > > > > On any output buses or input buses, all data running on the buses are > > > mutually exclusive. > > > > I couldn't persuade James to change his mind. > Jim Lewis doesn't own the VHDL language standard nor is he a gatekeeper that prevents suggestions from being submitted. His clout kicks in more after the submission....but that's off on a tangent. > Keyword 'orif' has the same language grammar definition as 'elsif' > with one exception: conditional signal contained in leading 'if' or > 'elsif' segment and conditional signals contained in the subsequent > and contiguous 'orif' segment in an 'if' statement are mutually > exclusive. Where keyword 'elsif' can be used in a VHDL code, there > keyword 'orif' can be used. > > Here is an example on how to use keyword 'orif': > > If(E0 = '1') then > State_A <= E0_S; > Orif(E1 = '1') then > State_A <= E_S; > Orif(E2 = '1') then > State_A <= E2_S; > elsIf(E3 = '1') then > State_A <= E3_S; > Orif(E4 = '1') then > State_A <= E4_S; > Orif(E5 = '1') then > State_A <= E5_S; > elsIf(E6 = '1') then > ... > Doesn't grab me much but I don't find it offensive either, just different. > It has two mutually exclusive signal groups: signals E0, E1 and E2 are > mutually exclusive. So are signals E3, E4 and E5. Only because you say they are mutually exclusive though. I can guarantee exclusivity by using existing VHDL enumerated types and a single signal. > > The implementation benefits with FPGA are huge !!! > Might want to consider less use of the exclamation point in the future. > For example: > > OutBus has 64-bit width. > > OutBusA : process(RESET, CLK) > begin > if(RESET = '1') then > OutBus <= (others=>'0'); > elsif(CLK'event and CLK = '1') then > If(E0 = '1') then > OutBus <= Data0; > orif(E1 = '1') then > OutBus <= Data1; > orif(E2 = '1') then > OutBus <= Data2; > orif(E3 = '1') then > OutBus <= Data3; > orif(E4 = '1') then > OutBus <= Data4; > orif(E5 = '1') then > OutBus <= Data5; > end if; > end if > end process; > > 1. If the keyword 'orif' is adopted as a VHDL standard, the above > equation would be executed in FPGA chips not by mux, not by case > statement implementation method, but by the most efficient method: > carry chain in Xilinx chips !!! > > It would be executed like a sum of products: In assembly language for > shortness: > OutBus = E0*Data0 + E1*Data1 + ... + E5*Data5; You seem to be forgetting the multiply operation in your above equation it's not 'just' adding Data0, Data1, etc. Also, if I were faced with this situation and today's syntax I would probably code it as... OutBus = F(E0, Data0) + F(E1, Data1) + ... + F(E5, Data5); where F() is a function that returned either the second argument or 0 based on how the first argument is set...in other words a simple couple line function that accomplishes a specific task. If the number of 'Data' elements was parameterized I might decide to embed that into the function as well and pass in an array of 'Data' instead of 'Data0'...'Data5'....but that's just me. > Please check Xilinx application note about how to implement sum of the > products (I failed to find it) Hmmm....don't think you gain much credibility with that statement. > > In other words, if keyword 'orif' is introduced into VHDL standard, > Xilinx carry chain structure would become part of VHDL standard in a > natural way. 'orif' will be refered to carry chain in FPGA > structure !!! You seem to be forgetting something very basic....if it can be implemented with a carry chain at all, it can be done with today's syntax as well. > 2. If the keyword 'orif' is adopted as a VHDL standard, it can specify > that during simulation, if a simulator detects two signals being > active in a mutually exclusive group on current cycle, simulator > issues a fatal error and stops without any user's interference !!! Hmmm....but you said that they were mutually exclusive but now you're alluding to the possibility that they might not. So what would happen in the implemented hardware? No assertions there, just logic implemented as LUT (FPGA), and/or (CPLD), gates (ASIC). The hardware will do something and it probably will do something inappropriate without a language guarantee that the collection is mutually exclusive as it is supposed to be....which is precisely what enumerated types do for you. > > Simple and reliable !!! You haven't sold me on the 'reliable' part. The 'simple' part is OK, but it's not much simpler than what can be done today so the relative measure of 'simple' is pretty low in this case in my opinion. Having to wonder about how exclusivity is guaranteed, how can I mess it up and things like that don't excite me. > > 3. I expect Xilinx would be the first company to implement the new > keyword 'orif', because its fastest carry chain feature would be best > used in the situations without users' efforts to change its writing > patterns. Gosh I hope not....implement the language standard not somebody's extensions. > You may imagine 64-bit data bus would occupy a lot of space > and resources if not the best carry chains are referenced. And the > routine timing will be hugely saved and running frequency will hugely > boosted. Got anything to back up those claims? The language extension that you're proposing will do absolutely nothing to the final hardware, there will be no savings of any kind. What you're proposing is (at best) a designer productivity improvement (i.e. lines of working code per unit of time). To suggest that a new language keyword would result in better resource usage is suspect. Have you benchmarked exactly how things get implemented today using functionally equivalent logic? Boolean logic does not require language keywords beyond 'and', 'or' and 'not'. Designer productivity increases with higher level abstractions but I'm not seeing much, if any, improvement to be gained by 'orif'. > > 4. 'orif' name is very appropriate. It means if above conditional > equation is not met, or try this one, or try next, or try the > last, ... it meets the equation above in assembly. 'elsif' on an enumerated type signal does that as well and is just as descriptive as 'orif'. > > 5. Most of programmers never use mutually exclusive property in their > designs and they fear the property would be violated some times. Got any basis for that statement? Programmers? Doing VHDL? I'd guess that they would catch on to either enumerated types or functions pretty quickly though. > But > here are some hints the violation situation will never happen if it is > appropriate. > > a. Data buses are always mutually exclusive !!! Does that even mean anything? > > If two data conditions on a data bus may be active at the same cycle, > add minimum additional conditions to make them mutually exclusive. And how do those conditions get satisfied and guaranteed? Hmmm... > > 7. Mutually exclusiveness is ubiquitout in logic design and I am very > sorry for VHDL without a special keyword to deal with it. What is it about enumerated types in VHDL that you find so hard? KJArticle: 123461
On Aug 28, 3:59 am, "Symon" <symon_bre...@hotmail.com> wrote: > "Weng Tianxiang" <wtx...@gmail.com> wrote in message > > news:1188263507.145095.110420@q3g2000prf.googlegroups.com... > > > > > It has two mutually exclusive signal groups: signals E0, E1 and E2 are > > mutually exclusive. So are signals E3, E4 and E5. > > > The implementation benefits with FPGA are huge !!! > > > For example: > > > OutBus has 64-bit width. > > > OutBusA : process(RESET, CLK) > > begin > > if(RESET = '1') then > > OutBus <= (others=>'0'); > > elsif(CLK'event and CLK = '1') then > > If(E0 = '1') then > > OutBus <= Data0; > > orif(E1 = '1') then > > OutBus <= Data1; > > orif(E2 = '1') then > > OutBus <= Data2; > > orif(E3 = '1') then > > OutBus <= Data3; > > orif(E4 = '1') then > > OutBus <= Data4; > > orif(E5 = '1') then > > OutBus <= Data5; > > end if; > > end if > > end process; > > Hi, > > I don't want to get involved in a language crusade, and I don't like to > crosspost so you'll need to read this on CAF, but why not just do something > like this? :- > > OutBusA : process(RESET, CLK) > begin > if(RESET = '1') then > OutBus <= (others=>'0'); > OutBus1 <= (others=>'0'); > OutBus2 <= (others=>'0'); > OutBus3 <= (others=>'0'); > OutBus4 <= (others=>'0'); > OutBus5 <= (others=>'0'); > elsif rising_edge(CLK) then > if (E1 = '1') then OutBus1 <= Data1; else OutBus1 <= (others=>'0'); end > if; > if (E2 = '1') then OutBus2 <= Data2; else OutBus2 <= (others=>'0'); end > if; > if (E3 = '1') then OutBus3 <= Data3; else OutBus3 <= (others=>'0'); end > if; > if (E4 = '1') then OutBus4 <= Data4; else OutBus4 <= (others=>'0'); end > if; > if (E5 = '1') then OutBus5 <= Data5; else OutBus5 <= (others=>'0'); end > if; > OutBus <= OutBus1 or OutBus2 or OutBus3 or OutBus4 or OutBus5; > end if > end process; > > Google comp.arch.fpga for a thread subject :- > > Multidimensional Register in Modul Port List > > and read Mr. Bromley's posts. > HTH., Syms.- Hide quoted text - > > - Show quoted text - Hi Syms, Your code timing is fundamantally inferior to my code timing. In your code, you specify 6 groups of data registers, then each bit of its output registers gets a combinational bit output. In my code, all 5 groups of signals are combinational signals and through a carry chain structure in FPGA, the output registers get the fastest clock-to-output timing result. WengArticle: 123462
Zorjak wrote:
> I'll try to use input and output behavioral in diferent process.
Here's a related example:
http://home.comcast.net/~mike_treseler/oe_demo.vhd
http://home.comcast.net/~mike_treseler/oe_demo.pdf
-- Mike Treseler
Article: 123463Andy and Mike, >> From Mike >> I get really frustrated when I try to implement something using >> standard VHDL and find that it is incorrectly or incompletely >> supported. I wish more people would have higher standards with the >> software they use. The way I see it, it's false advertising to >> advertise something as a VHDL synthesizer if it doesn't completely >> implement the VHDL standard, but not many seem to agree with me. >> >> I think it comes down to the difference between engineers and >> scientists. Scientists prefer theory, and deviations from the ideal >> grate on us. Engineers prefer practicality, and will tend to solder on >> (pun intended) through crappy software, more interested in the end >> result than the process. I have grounding in both, so I complain as I >> implement, and depend less on crappy software whenever the chance >> presents itself. Life's too short for bad software. I think the status-quo is more complex than you state. Vendors don't implement standards just because just because they have neat features. It is about marketing and investing. A vendor invests in features that will make them money and/or differentiate their software from a competitors. If you want change, you need to focus on communicating to them what features you require. They listen best to the people with $$$, so you may wish to file bug reports with both your vendor and with the person paying for the tools (or at least let the person paying for tools know about open bugs on a regular basis). Short of this, we would all have to pool together and talk to them collectively. > from Andy > There is an ieee standard for the "minimum" synthesizable subset of > vhdl, but its creation was dominated by the big player(s) in > synthesis, and focused on what they had already implemented. Actually most big players did not participate. At the time there were concerns with loosing patents due to standards participation. The theory behind the minimum was so a IP supplier would have a standard to claim compliance to. The second standard actually was started as soon as the first one was done, so I still believe it was the best decision. > Since then, updates to the standard have been few and far between, The first revision was 1076.6-1999 and 1076.6-2004. While that is slow, standards are a volunteer effort. You get what you invest. We need more user companies who are interested in this to invest the time. > and the standard has also migrated from a template based approach, > to a behavioral approach. An idea put forward by tool vendors. At the time it seemed to be a good way to avoid having a huge set of templates and leaving a few critical ones behind. At this point, the standard is due for revision by 2009. Since vendors have not implemented all of it, it would be an opportune time to change the approach if it is appropriate to do so. Myself, I am tied up with the general language revision, however, it is a good "starter" place for participating in standards. Particularly for experienced designers who regularly voice an opinion here (like Andy J, Mike T, Jon B, KJ, ... not meaning to leave any interested party out). Quit bitching, get the vendors involved and make it a standard you can live with and a standard the vendors will implement. Cheers, JimArticle: 123464
>
> Hi Syms,
> Your code timing is fundamantally inferior to my code timing.
>
> In your code, you specify 6 groups of data registers, then each bit of
> its output registers gets a combinational bit output.
>
> In my code, all 5 groups of signals are combinational signals and
> through a carry chain structure in FPGA, the output registers get the
> fastest clock-to-output timing result.
>
> Weng
>
I knew this would happen...
Is this 'fundamentally inferior'?
OutBus1 <= Data1 when (E1 = '1') else OutBus1 <= (others=>'0');
OutBus2 <= Data2 when (E1 = '1') else OutBus2 <= (others=>'0');
OutBus3 <= Data3 when (E1 = '1') else OutBus3 <= (others=>'0');
OutBus4 <= Data4 when (E1 = '1') else OutBus4 <= (others=>'0');
OutBus5 <= Data5 when (E1 = '1') else OutBus5 <= (others=>'0');
OutBus : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
OutBus <= OutBus1 or OutBus2 or OutBus3 or OutBus4 or OutBus5;
end if
end process;
I think Mike's comment sums it up...
HTH., Syms.
Article: 123465
Weng,
> Hi,
> I open a new topics from previous one to try to stir another round to
> introduce a new keyword 'orif'.
My conclusion from our numerous previous discussions
on this topic are that for simple cases it looks
intuitive and makes the syntax look deceptively
attractive, however, for more interesting conditions,
it becomes difficult if not impossible to identify the
mutually exclusive items and, hence, you will get
little to no benefit from it. So I was tickled to see
that SystemVerilog decided to implement something similar
to this, however, I would suspect that they do not give
you quite the flexibility that you want.
On the other hand, as I mentioned previously and Andy
pointed out in the thread you quoted (repeated below):
"For dynamic mutex inputs, verification is best
handled in an assertion. If a standardized one_hot() or zero_one_hot()
function could be created (to operate on an unconstrained vector of
booleans, for example), then synthesis could recognize their use in an
assertion, and make the appropriate optimizations automatically,
without affecting the syntax or structure of the language. The
assertion (or other code) could also control what happens when, in
fact, the conditions are not mutually exclusive (the same way the
language handles indices out of bounds, etc.). In other words, in
order to gain that level of control over what happens if mutex is not
true, you'd have to use the same amount of code for either solution,
and the latter solution does not require a change to the language."
I also note that some synthesis tools have started to support assertions
in synthesis. Synthesis support is a separate topic and is similar
whether it is an assertion or a built-in language feature.
For your code of the form:
If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;
The assertion that would allow this code to be written with only elsif is:
assert zero_one_hot (E0, E1, E2) ;
I noted that in your code you mixed orif mixed with elsif (copied below),
was this intentional? One hand, these could convey exactly what I want
(because there are many cases like this), OTOH, it could be a mistake.
Hence the intent is ambiguous and during a design review, one would have
to pay particular attention to this and ask questions about your intent
and its validation. A copy of your code is below.
If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;
elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then
On the other hand, with assertions, the following assertions
allow the above code to be written using elsif. In addition,
in this case, it is very clear about which I want to be
mutually exclusive.
assert zero_one_hot (E0, E1, E2) ;
assert zero_one_hot (E3, E4, E5) ;
Also note that if you are using std_logic or bit types, with the
Accellera VHDL-2006 revision you can write:
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;
You can also leave out the = '1' in VHDL-2006:
if E0 or E1 or E2 or E3 or E4 or E5 then
I also note that SystemVerilog added the keywords priority and
unique. The danger in adding new keywords is that they may
conflict with a name (signal, ...) already used in someone's design
and cause an old design to be a syntax error in the new language
revision. This generally does not please people and means they
have to add special handling for the file (compile flags).
What we need in the future revisions of the language is capability.
This does not necessarily mean adding new keywords.
> 7. Mutually exclusiveness is ubiquitout in logic design ...
I agree with this part. The language needs a capability to effectively
handle mutual exclusion.
The PSL extension brings us one_hot and zero_one_hot functions.
These functions are visible within a PSL assert statement (but not
a VHDL assert statement). As a result as long as you used a form
of assert that is compatible with PSL, you can do this with any
simulator or synthesis tool that supports Accellera VHDL-2006.
If the tool does not support it, you can file a bug and/or
enhancement against it to get the feature added.
If you wish to continue this discussion, please re-post (from 1 year
ago?) that show your more complex examples, identify the conditions
that you want to be mutually exclusive, and explain how you think
a tool should extract/determine those conditions.
Best,
Jim
Article: 123466"Mike Treseler" <mike_treseler@comcast.net> wrote in message news:5jiqhcF3ubforU1@mid.individual.net... > eli.billauer@gmail.com wrote: > >> Now to my suggestion: The problem is that paths which end up in the >> flip-flops' CE pin are taken for multi-cycle paths. > > I don't follow this. > A clock enable is just a synchronous input. > Which tool automatically constrains timing for these? > > -- Mike Treseler Hi Mike, He's trying to ensure the enable signal gets to all the FFs in time. This should happen anyway as long as he keeps the instance 'en' out of his timegroup 'tgrp_en' which he may or may not have done. I think there's a flaw in his logic, in that the enable doesn't necessarily attach to the .CE pins. It can go to regular logic depending on the synthesisers 'day_of_week' input. :-) Also, CE pins get used for other things the synthesiser decides on. Cheers, Syms.Article: 123467
"maxascent" <maxascent@yahoo.co.uk> wrote in message news:Tridnc8MvtlxvEnb4p2dnAA@giganews.com... > > Hi > > I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there a > general rule of how many layers the pcb will need to route out all the > pins? > > Cheers > > Jon Use laser drilled microvias. You'll save the extra money they cost on by reducing the number of layers by 4. You only need them on the same side as the BGA. Layer 1 <-> Layer 2. All the other vias can be through. HTH., Syms.Article: 123468
On Aug 28, 10:17 am, "Symon" <symon_bre...@hotmail.com> wrote: > > Hi Syms, > > Your code timing is fundamantally inferior to my code timing. > > > In your code, you specify 6 groups of data registers, then each bit of > > its output registers gets a combinational bit output. > > > In my code, all 5 groups of signals are combinational signals and > > through a carry chain structure in FPGA, the output registers get the > > fastest clock-to-output timing result. > > > Weng > > I knew this would happen... > > Is this 'fundamentally inferior'? > > OutBus1 <= Data1 when (E1 = '1') else OutBus1 <= (others=>'0'); > OutBus2 <= Data2 when (E1 = '1') else OutBus2 <= (others=>'0'); > OutBus3 <= Data3 when (E1 = '1') else OutBus3 <= (others=>'0'); > OutBus4 <= Data4 when (E1 = '1') else OutBus4 <= (others=>'0'); > OutBus5 <= Data5 when (E1 = '1') else OutBus5 <= (others=>'0'); > > OutBus : process(RESET, CLK) > begin > if(RESET = '1') then > OutBus <= (others=>'0'); > elsif rising_edge(CLK) then > OutBus <= OutBus1 or OutBus2 or OutBus3 or OutBus4 or OutBus5; > end if > end process; > > I think Mike's comment sums it up... > > HTH., Syms. Hi Syms, 1. Are you sure that Xilinx FPGA compiler will generate a carry chain structure to meet your design requirements? You must pray they would do so, but with new keyword 'orif' Xilinx FPGA compiler will be mandated to map 'orif' structure into a carry chain structure without doubt. That will be the benefit everyone would enjoy. Letting a special VHDL language structure refer to a carry chain implementation in FPGA is a wonderful thing. 2. Which writing pattern between ours is better, more concise and more impressive with the price of a new keyword 'orif' introduction? I know that anything can be written in one way or the other in VHDL, but mutually exclusiveness is an ubiquitous phenomenon and it should be reflected in VHDL language structure. Its referring to carry chain in FPGA is really a God's gift, why don't we accept it? WengArticle: 123469
On Aug 28, 8:35 am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Thanks for all the info. I think I may be able to get away with using 8 as > not all of the banks are fully utilised. > > Jon If do you have to route GTPIO transcievers and you'll probably want stripline then 8 layers could be at limit. VasileArticle: 123470
On Aug 28, 6:41 am, Gabor <ga...@alacron.com> wrote: > On Aug 28, 9:23 am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > > > Hi > > > I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there a > > general rule of how many layers the pcb will need to route out all the > > pins? > > > Cheers > > > Jon > > In the Virtex 2 users guide there are suggested breakout routings > for each package. There should be similar documentation for V4. > Note that your layer count will depend on the design rules you > choose for pcb manufacture. At 1mm spacing, you may need to > reduce your via drill size to 10 mils (gotta love mixed units > of measure) and leave out unused pads on inner layers to allow > more routes between adjacent pads. With 5 mil width and spacing > and 12/25 mil via drill/pad you can only run 1 line between pads. > > We've made boards using similar dense packages using from > 8 to 12 layers depending on design rules. For at least the > suppliers we use, saving layer count reduces price significantly > even if you need to use fine (10 mil) drills. > > Suggested breakout patterns also require dogbone removal > on the outer two rings of pads. Hi Gabor, Could you point to a picture showing this tehnique ? I don't understand what exactly means "dogbone removal". thx, Vasile Be sure to run unconnected > outer pads to a test point since you won't be able to access > them without the dogbone / via. > > After you look at the breakout drawings, don't forget to add the > appropriate number of plane layers to deliver all of your > supply voltages. You may need more than 1 ground plane > depending on your I/O switching rates. > > Good Luck, > GaborArticle: 123471
Weng, I was almost starting to agree with you, until you said this... > with new keyword 'orif' Xilinx FPGA compiler will be >mandated to map 'orif' structure into a carry chain structure without >doubt. >... >Letting a special VHDL language structure refer to a carry chain >implementation in FPGA is a wonderful thing. This is the purest madness. If you want a language structure that specifies a particular implementation, you have it already: it's called a "primitive instance". I agree that a conditional that is mutually-exclusive by design can readily be mapped to specific hardware such as MUXCY or a tree of ORs, but the precise mapping is NOT something we want in the language, thanks very much. Tools must have the freedom to optimize as they think best, and must compete (and succeed or fail) on how effectively they do it. Language constructs that have built-in assertions for things that are otherwise hard to describe, such as mutual exclusivity, are something that is well worth exploring. Especially now that we have the partially- successful SystemVerilog example to study, it should be possible to come up with some interesting ideas. But please don't blast a hole in your own argument by demanding that the language construct should have a one-to-one mapping to some specific piece of technology. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 123472
On Aug 28, 4:15 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Tue, 28 Aug 2007 01:11:47 -0000,
>
> Weng Tianxiang <wtx...@gmail.com> wrote:
> >I open a new topics from previous one to try to stir another round to
> >introduce a new keyword 'orif'.
>
> Weng,
>
> It seems to me that what you are trying to do is very similar
> to SystemVerilog's "unique" and "priority" keywords. It is
> not completely clear from your posts exactly what the semantics
> of "orif" should be, but as I understand it you intend that
> "orif" should have exactly the same behaviour as "elsif",
> together with a mutual-exclusivity check so that it is an
> error if more than one of the "if" conditions is true.
> I agree that this is a desirable thing to be able to say.
>
> I do not fully understand how your combinations of "orif"
> and "elsif" are intended to work.
>
> It is also desirable to be able to specify that *at least*
> one of the conditions is true. And then you can combine
> the "at-least-one" and "at-most-one" tests to guarantee
> that there is EXACTLY one condition true. Note that
> SystemVerilog got this wrong, in my opinion: "unique"
> enforces exactly-one, and "priority" enforces at-least-one,
> so there is no easy way to specify at-most-one.
>
> It is easier in VHDL than Verilog, because the test
> expressions cannot have side-effects.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
Hi Jonathan,
1. How 'elsif' and 'orif' work together?
See the following example:
If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;
elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then
'if', 'elsif' and 'else' play a role like brackets, putting together a
group of signals that are grouped with 'orif' between them to specify
mutually exclusiveness : there are two groups: (E0, E1, E2), (E3, E4,
E5) and signals in each group are mutually exclusive. Other grammar
meanings remain unchanged: It also means that if one of (E0, E1, E2)
is true, then 'if' statement is finished, otherwise try to test (E3,
E4, E5), like an usual 'if' statement.
The keyword 'orif' only adds the meaning that all signals in the group
are mutually exclusive, no more meaning is added. But it is enough for
compiler to do a smart job with the extra information.
For example, in the above example, two parallel carry chains can be
generated, then another LUT to put them together or more efficient LUT
allocations.
What I want is to transfer to a VHDL compiler the information that
there is mutually exclusive information about them and use them in
best interest of timing.
3. "It is also desirable to be able to specify that *at least*
one of the conditions is true. "
No such requirement is needed based on the fact that any 'if'
statement is complete: it means there is at least one hit, no more
than 2.
For example, the following example :
if(..) then
...
orif(...)
...
orif(...)
...
else
... <--- default hit
end if;
if(..) then
...
orif(...)
...
orif(...)
...
end if;
Above example is logically equivalent to the following one:
if(..) then
...
orif(...)
...
orif(...)
...
else
null; <--- default hit
end if;
It likes the following example with 'elsif'
if(..) then
...
elsif(...)
...
elsif(...)
...
else
null; <--- default hit
end if;
3. I am not fimiliar with Verilog, but from Marcus posting, I know
there is a definitive advantage of my method over Verilog's:
You have never to specify "at-least-one" and "at-most-one" tests. No.
'if' statement structure in sequential process has already null
statement as its default value as following examples show.
A2 : process(RESET, CLK)
begin
if(RESET = '1') then
State_A <= State_0_S;
elsif(CLK'event and CLK = '1') then
case State_A is
when State_0_S =>
if(A = '1') then
State_A <= State_1_S;
else
null;
end if;
...
...
end case;
end if;
end process;
A3 : process(RESET, CLK)
begin
if(RESET = '1') then
State_A <= State_0_S;
elsif(CLK'event and CLK = '1') then
case State_A is
when State_0_S =>
if(A = '1') then
State_A <= State_1_S;
end if;
...
...
end case;
end if;
end process;
Jonathan, I would like to address any concern you will rise.
Thank you.
Weng
Article: 123473On Aug 28, 1:41 pm, "Symon" <symon_bre...@hotmail.com> wrote: > "maxascent" <maxasc...@yahoo.co.uk> wrote in message > > news:Tridnc8MvtlxvEnb4p2dnAA@giganews.com... > > > > > Hi > > > I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there a > > general rule of how many layers the pcb will need to route out all the > > pins? > > > Cheers > > > Jon > > Use laser drilled microvias. You'll save the extra money they cost on by > reducing the number of layers by 4. You only need them on the same side as > the BGA. Layer 1 <-> Layer 2. All the other vias can be through. > HTH., Syms. This sounds interesting. Are you using via-in-pad? Can you point me to a good source showing how to use microvia's to improve BGA routing? A quick Google search brought up lots of articles that assume you already know the basic premise. Just at first glance I would think that the inner portions of the BGA routing would still require traditional techniques? Regards, GaborArticle: 123474
On Aug 28, 11:38 am, Gabor <ga...@alacron.com> wrote: > On Aug 28, 1:41 pm, "Symon" <symon_bre...@hotmail.com> wrote: > > > > > > > "maxascent" <maxasc...@yahoo.co.uk> wrote in message > > >news:Tridnc8MvtlxvEnb4p2dnAA@giganews.com... > > > > Hi > > > > I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there a > > > general rule of how many layers the pcb will need to route out all the > > > pins? > > > > Cheers > > > > Jon > > > Use laser drilled microvias. You'll save the extra money they cost on by > > reducing the number of layers by 4. You only need them on the same side as > > the BGA. Layer 1 <-> Layer 2. All the other vias can be through. > > HTH., Syms. > > This sounds interesting. Are you using via-in-pad? Can you point > me to a good source showing how to use microvia's to improve BGA > routing? A quick Google search brought up lots of articles that > assume you already know the basic premise. Just at first glance > I would think that the inner portions of the BGA routing would > still require traditional techniques? At 1mm pitch, microvias in pad will not be a very good option. I've used microvia in pad for 0.65mm pitch and it was very expensive. There must be a low isolation thickness between layer 1-2 for microvias, and usually the board is requesting simmetry (if you have microvias on 1-2 then you may have on 7-8 but depends on stack). Vasile
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