Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 123525

Article: 123525
Subject: Re: New keyword 'orif' and its implications
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 29 Aug 2007 10:30:06 -0700
Links: << >>  << T >>  << A >>
KJ wrote:

>> 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?

I agree with KJ.
Enumerated types and values cover
designs with mutual exclusion very well
and are easy to read and to testbench.

Synthesis does a good job of encoding and
decoding enumerated values.

How hard should I work and what
risks should I take to save a LUT
by enforcing and verifying my own encoding?

         -- Mike Treseler

Article: 123526
Subject: PCIe question
From: "vsurducan@gmail.com" <vsurducan@gmail.com>
Date: Wed, 29 Aug 2007 11:08:14 -0700
Links: << >>  << T >>  << A >>
The lane signals should be AC coupled:
a. on the motherboard between the controller and PCIe socket
b. on the PCIe card between the FPGA GTP and PCIe PCB connector
c. on both

?
thx,
Vasile


Article: 123527
Subject: Re: PCIe question
From: "Charles, NG" <site_blackhole@trellisys.ie>
Date: Wed, 29 Aug 2007 20:55:02 +0200
Links: << >>  << T >>  << A >>
The spec says all _transmitters_ shall be AC coupled. You just lead the
RX line directly to your component.

In terms of your a) b) c) options, the answer is therefore c) but only
the TX line(s).

By the way as far as I remember, there is some Intel doc recommending
placing the cap at 1/3 of the distance from plug to component (i.e.
closer to the plug than to the component).

Article: 123528
Subject: Re: bidirectional pin help
From: Zorjak <Zorjak@gmail.com>
Date: Wed, 29 Aug 2007 12:30:47 -0700
Links: << >>  << T >>  << A >>
Thanks for all Your try to help Mikhail.

I contacted Altera suport (I use their FPGA) and they tell me this
------------------------------------------------------------------------------------------------------
I have compiled your design here on my computer and yes I also got the
message

Info: Pin test has VCC driving its datain port

Regarding this message, the fact is that an open-drain buffer is
implemented in the "test" I/O Buffer, as you can find on the "Output
Pins" page under the "Resource Section" of the "Fitter" report in the
Compilation Report window (Processing menu). The function of the open-
drain buffer is that when its input is 0, output is 0; when its input
is 1, output is high impedance. That's the reason why the datain port
of the "test" pin is driven by VCC.

Regarding the 5V voltage measurement result, generally when a signal
is in the high impedance state, there is still possibility that you
can probe out a high level voltage, although there is no or little
current strength on the signal. To confirm it is a high impedance
state, please connect the probe to GND through a resistor while
monitoring the signal. If a low logic level is monitored, it can be
demonstrated that the signal is in high-Z state actually.

Please let me know if you have further questions on it.

I try to conect this pin with ground throght resistor and it work just
as he said. But this doesn't solve problem to me. Do you maybe know,
is there posibility that when I have high impedance on output I have
0V on it. i read something about open drain and open source on net but
I didn't understood this very well.
I have to look it a lot more.

Anyway, I want to thank for all Your try to help.
Thanks again, Mikhail
Zoran


On Aug 29, 6:01 pm, "MM" <mb...@yahoo.com> wrote:
> "Zorjak" <Zor...@gmail.com> wrote in message
>
> news:1188286393.929728.116820@d55g2000hsg.googlegroups.com...
>
>
>
> > You se that I have one output pin called "test". It has only one
> > driving 'Z' (end of the process). But in my compilaton report I have
> > the same waring as with bidir pin. (Pin test has Vcc driving its
> > datain port). It's like that there is no problem if the pin is
> > biderctional or not. It is something with this "High Impedanse" as I
> > seee it. I am not shure about anything.
>
> Move your test <= Z line out of the process. Remember that a process fires
> only when there is an event on any of the signals on its sensitivity list.
> The processes are mostly used for describing synchronous circuits such as
> flip-flops. When combinatorial processes are used as is the case in your
> design it is very easy to get confused and synthesize something totally
> unexpected. When you do use processes remember to define default values for
> all the signals/variables...
>
> /Mikhail



Article: 123529
Subject: Re: PCIe question
From: Gabor <gabor@alacron.com>
Date: Wed, 29 Aug 2007 12:43:21 -0700
Links: << >>  << T >>  << A >>
On Aug 29, 2:55 pm, "Charles, NG" <site_blackh...@trellisys.ie> wrote:
> The spec says all _transmitters_ shall be AC coupled. You just lead the
> RX line directly to your component.
>
> In terms of your a) b) c) options, the answer is therefore c) but only
> the TX line(s).
>
> By the way as far as I remember, there is some Intel doc recommending
> placing the cap at 1/3 of the distance from plug to component (i.e.
> closer to the plug than to the component).


Also if you're designing a PCIe plug-in card, remember that the signal
names on the connector are based on the motherboard.  So you need to
connect your transmitter to the receive signals (PERP0/PERN0 ...) and
your receiver to the transmit signals (PETP0/PETN0 ...).  Since the Rx
and Tx signals are on the opposite board surface, it is very hard to
correct swapped signals using wires!  I got bit by this on my first
PCIe design.


Article: 123530
Subject: Re: PLL Power and m/n ratio
From: Gabor <gabor@alacron.com>
Date: Wed, 29 Aug 2007 12:50:19 -0700
Links: << >>  << T >>  << A >>
On Aug 29, 12:05 pm, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote:
> On Aug 28, 6:35 am, Paul Leventis <paul.leven...@gmail.com> wrote:
>
>
>
> > Hello Sanjay,
>
> > Our experience is that the PLL's power consumption is fairly low as
> > compared to the clock network it is driving in most cases. To get a
> > sense for the amount of power the PLL consumes as a function of the
> > VCO frequency, download a copy of the Early Power Estimator
> > spreadsheet for the device you are interested in (http://www.altera.com/support/devices/estimator/pow-powerplay.jsp).
>
> > For a more detailed analysis, grab a copy of Quartus and fire up a toy
> > design with the PLL in it, and run it through the PowerPlay Power
> > Analyser.  The PLL models for 90 nm and 65 nm devices take into
> > account your VCO frequency, M/N values, and counter settings.
>
> > Regards,
>
> > Paul Leventis
> > Altera Corp.
>
> I tried to use the Altera spreadsheet for Stratix3 device as that is
> what I am targetting at present.  It seems like the PLL power
> requirement changes only with the VCO frequency.  But I am guessing
> this does not say much as the VCO frequency will change depending upon
> the input frequency assuming output frequency is kept the same.


I think you mean to say "will _not_ change ... assuming output
frequency is kept the same"?

Normally the VCO frequency is the desired output frequency multiplied
by the required output divider.  Since your two input frequencies are
related (4:1) I would not expect you to change the output divider, and
therefore to end up with the same VCO frequency and (roughly) the same
power usage in either case.

Regards,
Gabor


Article: 123531
Subject: Registered output for Altera on-chip memory
From: =?iso-8859-1?B?RWRtb25kIENvdOk=?= <edmond.cote@gmail.com>
Date: Wed, 29 Aug 2007 20:35:47 -0000
Links: << >>  << T >>  << A >>
When generating a memory block for an Altera Stratix chip using the
Megafunction generator, the tool defaults to registering the 'q'
output port. I am curious, is there a particular reasoning behind this
choice? Performance maybe?

Thanks,

-- Edmond


Article: 123532
Subject: Re: bidirectional pin help
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 29 Aug 2007 17:06:19 -0400
Links: << >>  << T >>  << A >>
"Zorjak" <Zorjak@gmail.com> wrote in message 
news:1188415847.768226.105940@57g2000hsv.googlegroups.com...
>
> I try to conect this pin with ground throght resistor and it work just
> as he said. But this doesn't solve problem to me. Do you maybe know,
> is there posibility that when I have high impedance on output I have
> 0V on it. i read something about open drain and open source on net but
> I didn't understood this very well.
> I have to look it a lot more.
>

I can't see how one can measure 5V on an open drain output without a pullup 
resistor... Why is it 5V anyways? What kind of FPGA are you using? All of 
the modern FPGA use lower voltages...

Also, any unused pin should be tristated on your FPGA, so see what you will 
measure on unused pins... Then do what I said about taking the test signal 
assignment out of the process.


/Mikhail



Article: 123533
Subject: Difference in the JTAG instructions between Virtex and Virtex II
From: "shadabambat1@gmail.com" <shadabambat1@gmail.com>
Date: Wed, 29 Aug 2007 14:13:38 -0700
Links: << >>  << T >>  << A >>
Hi, I am writing a C/C++ driver for programming a Virtex 2 using the
JTAG port (Parallel III cable) since it's required for a particular
application (JBits)

I found the required boundary scan instruction sequence needed to do
this from http://direct.xilinx.com/bvdocs/appnotes/xapp139.pdf
the instruction sequences were defined for the Virtex so would it also
apply for the Virtex 2? If not what changes are needed or is there any
material that I can refer to?

Shadab


Article: 123534
Subject: Re: bidirectional pin help
From: Zorjak <Zorjak@gmail.com>
Date: Wed, 29 Aug 2007 14:36:55 -0700
Links: << >>  << T >>  << A >>
Mikhail,

I am using cyclone ep1c6q240c8 (UP3-1c6 development kit)
I don't know too, how can I can measure 5V. How much I understand this
FPGA it should work on 3.3V. That confused me to.
I have mesured unused pins voltage (Yes, they are defined as input 3
stated) and I have also got 5V.
I am totaly confused about all of this.

I have tried to put test signal out of pocess statement and nothing.
Same waring, same measure result. "pin testhas Vcc driving his datain
port".

Thanks again for Your try to help. I don't know what to say more:):)
Zoran



On Aug 29, 11:06 pm, "MM" <mb...@yahoo.com> wrote:
> "Zorjak" <Zor...@gmail.com> wrote in message
>
> news:1188415847.768226.105940@57g2000hsv.googlegroups.com...
>
>
>
> > I try to conect this pin with ground throght resistor and it work just
> > as he said. But this doesn't solve problem to me. Do you maybe know,
> > is there posibility that when I have high impedance on output I have
> > 0V on it. i read something about open drain and open source on net but
> > I didn't understood this very well.
> > I have to look it a lot more.
>
> I can't see how one can measure 5V on an open drain output without a pullup
> resistor... Why is it 5V anyways? What kind of FPGA are you using? All of
> the modern FPGA use lower voltages...
>
> Also, any unused pin should be tristated on your FPGA, so see what you will
> measure on unused pins... Then do what I said about taking the test signal
> assignment out of the process.
>
> /Mikhail



Article: 123535
Subject: Output signals not synchronized
From: EEngineer <maricic@gmail.com>
Date: Wed, 29 Aug 2007 21:39:37 -0000
Links: << >>  << T >>  << A >>
I have 23bit wide RAM that I use as ROM inferred from the code. When I
use the logic analyser (Agilent 16903A) with the finest resolution of
2.5ns I see that signals on the output header are not read
synchronously - some of them are 2.5 or 5ns delayed and that is a
problem.
I have used this line in constraints UCF file

NET ctrl_data<*> TNM=ctrl_data_group;
TIMEGRP "ctrl_data_group" OFFSET = OUT 100 ps AFTER "SYSCLK_100MHZ"
HIGH ;

but this did not help. This SYSCLK_100MHZ clock is divided by 16 in
order to read the ctrl_data that is 23bit wide memory.

Any suggestions?

Thanks,
Dan


Article: 123536
Subject: SDF File basics
From: "asic1234@gmail.com" <asic1234@gmail.com>
Date: Wed, 29 Aug 2007 21:49:09 -0000
Links: << >>  << T >>  << A >>
What does SDF, and Back-annotation/Forward annotation mean? How is an
SDF File generated and by which tool?

Can someone explain how to do synthesis and what tools/file
extensions
(.sdf, .lib etc)  mean?


Article: 123537
Subject: Re: bidirectional pin help
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 29 Aug 2007 17:51:29 -0400
Links: << >>  << T >>  << A >>
"Zorjak" <Zorjak@gmail.com> wrote in message 
news:1188423415.369963.211260@o80g2000hse.googlegroups.com...
>
> I don't know too, how can I can measure 5V. How much I understand this
> FPGA it should work on 3.3V. That confused me to.
> I have mesured unused pins voltage (Yes, they are defined as input 3
> stated) and I have also got 5V.
> I am totaly confused about all of this.
>

OK, something is seriously wrong here. Let's start with your multimeter. 
Have you verified that it actually works? Try measuring power supplies on 
your board. Sorry if this will insult you, but make sure that while one of 
your probes touches the FPGA pin , another is at the board's ground.


/Mikhail 



Article: 123538
Subject: Re: Output signals not synchronized
From: EEngineer <maricic@gmail.com>
Date: Wed, 29 Aug 2007 22:36:39 -0000
Links: << >>  << T >>  << A >>
there are also UCF lines:

NET ctrl_data<*> SLEW = FAST;
NET ctrl_data<*> DRIVE = 2;
NET ctrl_data<*> IOSTANDARD = LVCMOS33;


Article: 123539
Subject: Re: New keyword 'orif' and its implications
From: Andy <jonesandy@comcast.net>
Date: Wed, 29 Aug 2007 15:44:00 -0700
Links: << >>  << T >>  << A >>
On Aug 29, 11:46 am, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
> wrote:
>
>
>
> > Jim,
>
> > On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote:
>
> > |----------------------------------------------------------------------=
----=AD|
> > |"Weng,                                                                =
    |
> > |[..]                                                                  =
    |
> > |                                                                      =
    |
> > |[..]                                                                  =
    |
> > |                                                                      =
    |
> > |I noted that in your code you mixed orif mixed with elsif (copied belo=
w), |
> > |was this intentional?  One hand, these could convey exactly what I wan=
t   |
> > |(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 ha=
ve  |
> > |to pay particular attention to this and ask questions about your inten=
t   |
> > |and its validation.  A copy of your code is below.                    =
    |
> > |                                                                      =
    |
> > |If(E0 =3D '1') then                                                   =
      |
> > |State_A <=3D E0_S;                                                    =
      |
> > |Orif(E1 =3D '1') then                                                 =
      |
> > |State_A <=3D E_S;                                                     =
      |
> > |Orif(E2 =3D '1') then                                                 =
      |
> > |State_A <=3D E2_S;                                                    =
      |
> > |elsIf(E3 =3D '1') then                                                =
      |
> > |State_A <=3D E3_S;                                                    =
      |
> > |Orif(E4 =3D '1') then                                                 =
      |
> > |State_A <=3D E4_S;                                                    =
      |
> > |Orif(E5 =3D '1') then                                                 =
      |
> > |State_A <=3D E5_S;                                                    =
      |
> > |elsIf(E6 =3D '1') then                                                =
      |
> > |"                                                                     =
    |
> > |----------------------------------------------------------------------=
----=AD|
>
> > Yes,
>
> > Weng really did intend to have both orif branches and elsif branches
> > in a single if statement (seenews:1188325844.164564.136940@z24g2000prh.=
googlegroups.com
> > ). I think the intention would be clearer with different
> > indentation. E.g.
> > If(E0 =3D '1') then
> >           State_A <=3D E0_S;
> >       Orif(E1 =3D '1') then
> >           State_A <=3D E_S;
> >       Orif(E2 =3D '1') then
> >           State_A <=3D E2_S;
>
> > elsIf(E3 =3D '1') then
> >           State_A <=3D E3_S;
> >       Orif(E4 =3D '1') then
> >           State_A <=3D E4_S;
> >       Orif(E5 =3D '1') then
> >           State_A <=3D E5_S;
> > elsIf(E6 =3D '1') then
> > --...
>
> > |----------------------------------------------------------------------=
----=AD|
> > |"[..]                                                                 =
    |
> > |                                                                      =
    |
> > |[..]  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).            =
    |
> > |                                                                      =
    |
> > |[..]"                                                                 =
    |
> > |----------------------------------------------------------------------=
----=AD|
>
> > A newly introduced reserved word would be guaranteed to not conflict
> > with old code by not being possible to misinterpret as a basic
> > identifier (basic_identifier ::=3D letter { [ underline ]
> > letter_or_digit), e.g. by starting with an underline or by containing
> > a percentage sign.
>
> > Best regards,
> > Colin Paul
>
> Hi Colin,
> Thank you for your support.
>
> You are the first big canon who gave full support behind the keyword
> 'orif' and gets full understanding of its meaning.
>
> My fighting for 'orif' recognition is not for my personal purpose, it
> is in the interest of HDL industry and academic world.
>
> You help clear up 3 things:
> 1. Indent two separate mutually exclusive groups to avoid confusion.
> I have never thought about it.
>
> 2. "Weng really did intend to have both orif branches and elsif
> branches
>  in a single if statement "
>
> I have really done it in 'orif' definition:
> "Where keyword 'elsif' can be used in a VHDL code, there keyword
> 'orif' can be used.", but failed to mention that directly. It seems to
> me that it is a reality and may never be mentioned specifically.
>
> I thought that "if...elsif..." statement structure was created by IBM
> in 1953 when designing Fortran language to meet software requirements:
> sequential comparison, one after another.
>
> In hardware world, HDL language must have a similar mainstream
> language structure to meet the 0-1 out of N selections in parallel.
> That was where keyword 'orif' came from.
>
> In my experiences, 'orif' is much easier than zero_one_hot() to use in
> practise in the same way as engineers rarely use single signal names
> to replace equations in if() or elsif().
>
> 3. "A newly introduced reserved word would be guaranteed to not
> conflict
> with old code"
>
> Jim's opinion is that if you introduce a new keyword 'orif', then even
> though 'orif' doesn't conflict with 'elsif', but it certainly would
> conflict with old signal name orif. This can never be avoided. But his
> new function name zero_one_hot() still has the same possibility to
> conflict with old signal function name zero_one_hot() if someone had
> used it before, but he never mentioned his same possibility.
>
> I would like to add more information.
> 1. 'case' statement is a special case with keyword 'orif', in other
> words, all 'case' statement can be written using keyword 'if...orif'
> structure.
>
> Example:
>
> case two_bits is
>    when "00" =3D>
>       ...
>    when "01" =3D>
>       ...
>    when "10" =3D>
>       ...
>    when others =3D>
>       ...
> end case;
>
> if(two_bits =3D "00") then
>   ...
> orif(two_bits =3D "01") then
>   ...
> orif(two_bits =3D "10") then
>   ...
> else  <-- equivalent to "when others =3D>"
>   ...
> end if;
>
> 2. Andy mentioned that he may be able to find something that is beyond
> the capability of 'orif', but within capability of zero_one_hot().
>
> Andy, you never have a chance to do so with signals.
> Reason: you have to implement an assign statement to reflect their
> mutually exclusive property, then you must use one of two conditional
> branch statements: case statement or if statement that are within
> 'orif' range.
>
> Mutually exclusiveness is not used for combinational signals.
>
> I don't have any idea if mutually exclusive property applies to
> variables.
>
> 3. As keyword 'orif' definition says, 'orif' only provides information
> about mutually exclusive property among a group of conditions.
> Compilers can do what they think is the best strategy as they want.
> But for FPGA, the 'orif' perfectly refers to carry chain structure in
> both Xilinx and Altera (I am not familiar with other FPGA products),
> it is a wonderful thing, but should not be a burden or a blame, as
> Jonathan indicated.
>
> Weng

Weng,

The fact that orif must be indented from elsif, is a very poor way to
indicate functional structure of code. That should be the first key
that orif is a very weak bandaid on a problem that has much better
solutions that have repeatedly been suggested for a variety of
reasons.

Even your explanation of the indentation ("Indent two separate
mutually exclusive groups to avoid confusion") remains ambiguous: are
the groups mutually exclusive, or are the members of each group
mutually exclusive only amongst those group members, or both?
Indentation may look prettier (and help avoid missing an "elsif"), but
it adds nothing to the clarity of purpose.

  "In my experiences, 'orif' is much easier than zero_one_hot() to use
in practise in the same way as engineers rarely use single signal
names to replace equations in if() or elsif()."

I've already told you that you do not need to use single signal names
with zero_one_hot() arguments anymore than you have to use them with
if/elsif/orif conditions; expressions can be used in both instances.
Nor are you limited to using expressions in either place; you can
assign a signal or variable, which will often be more readable in both
instances anyway. What "engineers rarely [or commonly] use" is not the
definition of good coding practice.

zero_one_hot() can always be prefixed with the standard package name
in which it is defined. Keywords, on the other hand cannot. I believe
that tricks like '_' and '%' on the front of new keywords are a
hideous hack, nevertheless befitting this whole orif concept.

Any synthesis tool that cannot figure out the code below (rewritten
from your example, but in standard vhdl with elsif) indicates mutually
exclusive conditions should be immediately uninstalled and returned to
the vendor for a full refund!

if(two_bits =3D "00") then
  ...
elsif(two_bits =3D "01") then
  ...
elsif(two_bits =3D "10") then
  ...
else  <-- equivalent to "when others =3D>"
  ...
end if;

As for mutual exclusivity of combinatorial signals or variables, why
do you think mutual exclusivity should be limited to registers only?
Even in  your own code examples you have demonstrated mutual
exclusivity of intermediate expressions, which are not registers.

I don't understand your reference to having "to implement an assign
statement to reflect their mutually exclusive property, then you must
use one of two conditional branch statements: case statement or if
statement that are within 'orif' range.

You are completely missing the point about using an assertion: the
assertion is completely independent of the functional code. It merely
provides additional information to a tool that may or may not use it,
but most importantly, it does not restrict you to a specific
functional coding method in order to provide that information.

Your statement: "3. As keyword 'orif' definition says, 'orif' only
provides information about mutually exclusive property among a group
of conditions. " is incorrect: it also provides the functional part,
and cannot be separated from it.

For example, how would you use orif in a loop to do the following (the
loop is necessary because the range of enable is arbitrary):

data <=3D (others =3D> '0');
if read =3D '1' then
  for i in enable'range loop
    if enable(i) =3D '1' then
      data <=3D input(i);
      exit;
    end if;
  end loop;
  assert zero_one_hot(enable);
end if;

The answer is: you couldn't! The use of the assertion, since it is
independent of the functional code, places no limitations on how you
code the functional part.

OTOH, you can choose to combine it with the functional code to easily
represent conditional mutual exclusivity (i.e. only if read =3D '1'), as
shown above.

OTOOH, if enable was always mutex, it could be indicated once with an
assertion, and any logic that uses it anywhere else could be optimized
because of the additional information.

Andy


Article: 123540
Subject: Re: Question about xflow?
From: Duth <premduth@gmail.com>
Date: Wed, 29 Aug 2007 22:49:22 -0000
Links: << >>  << T >>  << A >>
On Aug 29, 4:50 am, fl <rxjw...@gmail.com> wrote:
> Hi,
> Now, I learn xflow ofxilinx. I want to generate a functionsimulation
> output file. For the example vhdl file: watchvhd, according to the
> Development System Reference Guid, I use the command:
>
> xflow -p xc2vp2-7fg256 -fsim modelsim_vhdl.opt stopwatch
>
> It generates a file: func_sim.vhdl
>
> My question is: How can I use it in Modelsim?
> Thanks in advance

Hi Fl,

The term functional simulation is kind of misleading. What you will
get is a post translate netlist when you run this. This will
synthesize your design run through ngdbuild and then run netgen to
give you a structural netlist of your design. If you want to run a
pure functional simulation then you probably want to use RTL files.

Once you have the netgen output file, just compile it in modelsim and
run the simulation with your testbench.

Xilinx Reference Solution Record: 1078
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=1078

Hope this helps
Thanks
Duth


Article: 123541
Subject: Re: how to keep all settings between runs
From: Duth <premduth@gmail.com>
Date: Wed, 29 Aug 2007 22:52:27 -0000
Links: << >>  << T >>  << A >>
On Aug 27, 2:04 am, b...@vandeenensupport-com.invalid (Bart van
Deenen) wrote:
> Duth <premd...@gmail.com> wrote:
> > On Aug 26, 4:00 am, b...@vandeenensupport-com.invalid (Bart van
> > Deenen) wrote:
> > > Is there a way to keep the settings (specifically the format of signals,
> > > and the widht of the name and value column) between runs of thesimulator?
> > > I find it quite tedious to keep selecting binary for one of my channels,
> > > and decimal for one of the others every time I run it again.
> >ISESimulatorshould save all the information about your signals from
> > run to run by default. Especially to do with the signals and their
> > individual settings. This is a new capability inISE9.1i, so if you
> > are using any older version of thesimulator, please upgrade toISE
> > 9.2i, which is the latest version where any issues with this is fixed.
> > There are some limitations and that has to do with keeping your
> > markers and so on saved, although the fix for this is coming soon.
>
> I have 9.2.0i running on Linux.
>
> When I start the simulation again, it does keep the traces, and the
> number format on the trace display, but not on the value column.
> I only now realize that there seems to be a bug in the value column
> display; it will always initially show values in hex (or binary), even
> though the corresponding trace shows decimal values (for instance).
> When you then select "decimal" with the contextual menu, the value
> column field will also show decimal.
> The column widths for the names and values are not saved between runs.
>
> Thanks for your help.
>
> Bart van Deenen

HI Bart,

Yes that specific issue you are running into is a bug. I believe it is
fixed in the latest service pack. If it is not, then it is definitely
in 10.1. In the next release the value column and the trace area will
always match. There was a bug in the tool that was why the two were
out of sync.

Thanks
Duth


Article: 123542
Subject: Re: bidirectional pin help
From: Zorjak <Zorjak@gmail.com>
Date: Wed, 29 Aug 2007 16:14:30 -0700
Links: << >>  << T >>  << A >>
:):) You didn't insult me, Mikhail

My multimetar  works fine, I am positive about that, I measure some
other things with it and it is ok. And, Yes when I measure the voltage
on FPGA pin another probe touch ground. I am 100% shure. Maybe,
somewhere on the board is 3.3V to 5.V converter, I didn't pay much
attention about that. I'll have to look about that Although this thing
obout this board and fpga is confusing, I have more wories about this
warring that I am getting from the quartus. It clearly says that this
pin constantly geting Vcc on it. I could bet that this is some
problem, not on the board. Mybe on the fpga is some pull up resistor
and it can't be turned off. I don't know what else could be.

Thanks again
Zoran



On Aug 29, 11:51 pm, "MM" <mb...@yahoo.com> wrote:
> "Zorjak" <Zor...@gmail.com> wrote in message
>
> news:1188423415.369963.211260@o80g2000hse.googlegroups.com...
>
>
>
> > I don't know too, how can I can measure 5V. How much I understand this
> > FPGA it should work on 3.3V. That confused me to.
> > I have mesured unused pins voltage (Yes, they are defined as input 3
> > stated) and I have also got 5V.
> > I am totaly confused about all of this.
>
> OK, something is seriously wrong here. Let's start with your multimeter.
> Have you verified that it actually works? Try measuring power supplies on
> your board. Sorry if this will insult you, but make sure that while one of
> your probes touches the FPGA pin , another is at the board's ground.
>
> /Mikhail



Article: 123543
Subject: Re: Output signals not synchronized
From: "John_H" <newsgroup@johnhandwork.com>
Date: Wed, 29 Aug 2007 16:40:54 -0700
Links: << >>  << T >>  << A >>
"EEngineer" <maricic@gmail.com> wrote in message 
news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
> there are also UCF lines:
>
> NET ctrl_data<*> SLEW = FAST;
> NET ctrl_data<*> DRIVE = 2;
> NET ctrl_data<*> IOSTANDARD = LVCMOS33;

To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not 
something that will make your outputs happen coincident with your clock, 
it's a specification that will simply fail in the place & route and timing 
analyzer.  Take a look.  The fastest your outputs will go depend on how fast 
an IOB register can deliver its output relative to your global clock.  These 
numbers are documented and easy to prototype.

Second, the 2 mA drive level will give you a slower rise/fall.  The skew in 
your output signal time can - depending on your load - be a noticeable time 
difference.

Third, the logic analyzer is an asynchronous device which will usually 
provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns 
difference not explained by the test equipment.

Please find the online documentation (or a Xilinx class) that describes what 
you can and cannot do with constraints.  This fundamental information 
usually is only understood after an engineer can't understand why their 
design isn't working.  Learn it. 



Article: 123544
Subject: Re: PCIe question
From: vasile <piclist9@gmail.com>
Date: Thu, 30 Aug 2007 00:48:26 -0000
Links: << >>  << T >>  << A >>
On Aug 29, 12:43 pm, Gabor <ga...@alacron.com> wrote:
> On Aug 29, 2:55 pm, "Charles, NG" <site_blackh...@trellisys.ie> wrote:
>
> > The spec says all _transmitters_ shall be AC coupled. You just lead the
> > RX line directly to your component.
>
> > In terms of your a) b) c) options, the answer is therefore c) but only
> > the TX line(s).
>
> > By the way as far as I remember, there is some Intel doc recommending
> > placing the cap at 1/3 of the distance from plug to component (i.e.
> > closer to the plug than to the component).
>
> Also if you're designing a PCIe plug-in card, remember that the signal
> names on the connector are based on the motherboard.  So you need to
> connect your transmitter to the receive signals (PERP0/PERN0 ...) and
> your receiver to the transmit signals (PETP0/PETN0 ...).  Since the Rx
> and Tx signals are on the opposite board surface, it is very hard to
> correct swapped signals using wires!  I got bit by this on my first
> PCIe design.

Thx for attentioning but my intention is to route differential signals
on stripline
(between ground planes) and I guess will be no wire.
I'm designing both the PCIe card and the motherboard and...

Vasile


Article: 123545
Subject: Re: PCIe question
From: vasile <piclist9@gmail.com>
Date: Thu, 30 Aug 2007 00:49:57 -0000
Links: << >>  << T >>  << A >>
On Aug 29, 5:50 pm, PeteS <axk...@dsl.pipex.com> wrote:
> Gabor wrote:
> > On Aug 29, 2:55 pm, "Charles, NG" <site_blackh...@trellisys.ie> wrote:
> >> The spec says all _transmitters_ shall be AC coupled. You just lead the
> >> RX line directly to your component.
>
> >> In terms of your a) b) c) options, the answer is therefore c) but only
> >> the TX line(s).
>
> >> By the way as far as I remember, there is some Intel doc recommending
> >> placing the cap at 1/3 of the distance from plug to component (i.e.
> >> closer to the plug than to the component).
>
> > Also if you're designing a PCIe plug-in card, remember that the signal
> > names on the connector are based on the motherboard.  So you need to
> > connect your transmitter to the receive signals (PERP0/PERN0 ...) and
> > your receiver to the transmit signals (PETP0/PETN0 ...).  Since the Rx
> > and Tx signals are on the opposite board surface, it is very hard to
> > correct swapped signals using wires!  I got bit by this on my first
> > PCIe design.
>
> It is very important to make sure your coupling capacitor is large
> enough to handle the 30kHz beacons, so *if* (as I do on occasion) you ac
> couple at _each end of the link_, make sure you used double the
> recommended value of capacitor if it's a short (in the transmission line
> sense) link.

This is new for me. What do you mean with 30KHz beacon at 3.1Gbps ?
The 0.1uF impedance is large enough for a Ghz signal.



Article: 123546
Subject: Re: PCIe question
From: PeteS <axkz70@dsl.pipex.com>
Date: Wed, 29 Aug 2007 20:50:57 -0400
Links: << >>  << T >>  << A >>
Gabor wrote:
> On Aug 29, 2:55 pm, "Charles, NG" <site_blackh...@trellisys.ie> wrote:
>> The spec says all _transmitters_ shall be AC coupled. You just lead the
>> RX line directly to your component.
>>
>> In terms of your a) b) c) options, the answer is therefore c) but only
>> the TX line(s).
>>
>> By the way as far as I remember, there is some Intel doc recommending
>> placing the cap at 1/3 of the distance from plug to component (i.e.
>> closer to the plug than to the component).
> 
> 
> Also if you're designing a PCIe plug-in card, remember that the signal
> names on the connector are based on the motherboard.  So you need to
> connect your transmitter to the receive signals (PERP0/PERN0 ...) and
> your receiver to the transmit signals (PETP0/PETN0 ...).  Since the Rx
> and Tx signals are on the opposite board surface, it is very hard to
> correct swapped signals using wires!  I got bit by this on my first
> PCIe design.
> 

It is very important to make sure your coupling capacitor is large 
enough to handle the 30kHz beacons, so *if* (as I do on occasion) you ac 
couple at _each end of the link_, make sure you used double the 
recommended value of capacitor if it's a short (in the transmission line 
sense) link.

Cheers

PeteS

Article: 123547
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 29 Aug 2007 18:11:48 -0700
Links: << >>  << T >>  << A >>
On Aug 29, 3:44 pm, Andy <jonesa...@comcast.net> wrote:
> On Aug 29, 11:46 am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
>
>
>
>
> > On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
> > wrote:
>
> > > Jim,
>
> > > On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote:
>
> > > |--------------------------------------------------------------------=
------=AD=AD|
> > > |"Weng,                                                              =
      |
> > > |[..]                                                                =
      |
> > > |                                                                    =
      |
> > > |[..]                                                                =
      |
> > > |                                                                    =
      |
> > > |I noted that in your code you mixed orif mixed with elsif (copied be=
low), |
> > > |was this intentional?  One hand, these could convey exactly what I w=
ant   |
> > > |(because there are many cases like this), OTOH, it could be a mistak=
e=2E    |
> > > |Hence the intent is ambiguous and during a design review, one would =
have  |
> > > |to pay particular attention to this and ask questions about your int=
ent   |
> > > |and its validation.  A copy of your code is below.                  =
      |
> > > |                                                                    =
      |
> > > |If(E0 =3D '1') then                                                 =
        |
> > > |State_A <=3D E0_S;                                                  =
        |
> > > |Orif(E1 =3D '1') then                                               =
        |
> > > |State_A <=3D E_S;                                                   =
        |
> > > |Orif(E2 =3D '1') then                                               =
        |
> > > |State_A <=3D E2_S;                                                  =
        |
> > > |elsIf(E3 =3D '1') then                                              =
        |
> > > |State_A <=3D E3_S;                                                  =
        |
> > > |Orif(E4 =3D '1') then                                               =
        |
> > > |State_A <=3D E4_S;                                                  =
        |
> > > |Orif(E5 =3D '1') then                                               =
        |
> > > |State_A <=3D E5_S;                                                  =
        |
> > > |elsIf(E6 =3D '1') then                                              =
        |
> > > |"                                                                   =
      |
> > > |--------------------------------------------------------------------=
------=AD=AD|
>
> > > Yes,
>
> > > Weng really did intend to have both orif branches and elsif branches
> > > in a single if statement (seenews:1188325844.164564.136940@z24g2000pr=
h=2Egooglegroups.com
> > > ). I think the intention would be clearer with different
> > > indentation. E.g.
> > > If(E0 =3D '1') then
> > >           State_A <=3D E0_S;
> > >       Orif(E1 =3D '1') then
> > >           State_A <=3D E_S;
> > >       Orif(E2 =3D '1') then
> > >           State_A <=3D E2_S;
>
> > > elsIf(E3 =3D '1') then
> > >           State_A <=3D E3_S;
> > >       Orif(E4 =3D '1') then
> > >           State_A <=3D E4_S;
> > >       Orif(E5 =3D '1') then
> > >           State_A <=3D E5_S;
> > > elsIf(E6 =3D '1') then
> > > --...
>
> > > |--------------------------------------------------------------------=
------=AD=AD|
> > > |"[..]                                                               =
      |
> > > |                                                                    =
      |
> > > |[..]  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).          =
      |
> > > |                                                                    =
      |
> > > |[..]"                                                               =
      |
> > > |--------------------------------------------------------------------=
------=AD=AD|
>
> > > A newly introduced reserved word would be guaranteed to not conflict
> > > with old code by not being possible to misinterpret as a basic
> > > identifier (basic_identifier ::=3D letter { [ underline ]
> > > letter_or_digit), e.g. by starting with an underline or by containing
> > > a percentage sign.
>
> > > Best regards,
> > > Colin Paul
>
> > Hi Colin,
> > Thank you for your support.
>
> > You are the first big canon who gave full support behind the keyword
> > 'orif' and gets full understanding of its meaning.
>
> > My fighting for 'orif' recognition is not for my personal purpose, it
> > is in the interest of HDL industry and academic world.
>
> > You help clear up 3 things:
> > 1. Indent two separate mutually exclusive groups to avoid confusion.
> > I have never thought about it.
>
> > 2. "Weng really did intend to have both orif branches and elsif
> > branches
> >  in a single if statement "
>
> > I have really done it in 'orif' definition:
> > "Where keyword 'elsif' can be used in a VHDL code, there keyword
> > 'orif' can be used.", but failed to mention that directly. It seems to
> > me that it is a reality and may never be mentioned specifically.
>
> > I thought that "if...elsif..." statement structure was created by IBM
> > in 1953 when designing Fortran language to meet software requirements:
> > sequential comparison, one after another.
>
> > In hardware world, HDL language must have a similar mainstream
> > language structure to meet the 0-1 out of N selections in parallel.
> > That was where keyword 'orif' came from.
>
> > In my experiences, 'orif' is much easier than zero_one_hot() to use in
> > practise in the same way as engineers rarely use single signal names
> > to replace equations in if() or elsif().
>
> > 3. "A newly introduced reserved word would be guaranteed to not
> > conflict
> > with old code"
>
> > Jim's opinion is that if you introduce a new keyword 'orif', then even
> > though 'orif' doesn't conflict with 'elsif', but it certainly would
> > conflict with old signal name orif. This can never be avoided. But his
> > new function name zero_one_hot() still has the same possibility to
> > conflict with old signal function name zero_one_hot() if someone had
> > used it before, but he never mentioned his same possibility.
>
> > I would like to add more information.
> > 1. 'case' statement is a special case with keyword 'orif', in other
> > words, all 'case' statement can be written using keyword 'if...orif'
> > structure.
>
> > Example:
>
> > case two_bits is
> >    when "00" =3D>
> >       ...
> >    when "01" =3D>
> >       ...
> >    when "10" =3D>
> >       ...
> >    when others =3D>
> >       ...
> > end case;
>
> > if(two_bits =3D "00") then
> >   ...
> > orif(two_bits =3D "01") then
> >   ...
> > orif(two_bits =3D "10") then
> >   ...
> > else  <-- equivalent to "when others =3D>"
> >   ...
> > end if;
>
> > 2. Andy mentioned that he may be able to find something that is beyond
> > the capability of 'orif', but within capability of zero_one_hot().
>
> > Andy, you never have a chance to do so with signals.
> > Reason: you have to implement an assign statement to reflect their
> > mutually exclusive property, then you must use one of two conditional
> > branch statements: case statement or if statement that are within
> > 'orif' range.
>
> > Mutually exclusiveness is not used for combinational signals.
>
> > I don't have any idea if mutually exclusive property applies to
> > variables.
>
> > 3. As keyword 'orif' definition says, 'orif' only provides information
> > about mutually exclusive property among a group of conditions.
> > Compilers can do what they think is the best strategy as they want.
> > But for FPGA, the 'orif' perfectly refers to carry chain structure in
> > both Xilinx and Altera (I am not familiar with other FPGA products),
> > it is a wonderful thing, but should not be a burden or a blame, as
> > Jonathan indicated.
>
> > Weng
>
> Weng,
>
> The fact that orif must be indented from elsif, is a very poor way to
> indicate functional structure of code. That should be the first key
> that orif is a very weak bandaid on a problem that has much better
> solutions that have repeatedly been suggested for a variety of
> reasons.
>
> Even your explanation of the indentation ("Indent two separate
> mutually exclusive groups to avoid confusion") remains ambiguous: are
> the groups mutually exclusive, or are the members of each group
> mutually exclusive only amongst those group members, or both?
> Indentation may look prettier (and help avoid missing an "elsif"), but
> it adds nothing to the clarity of purpose.
>
>   "In my experiences, 'orif' is much easier than zero_one_hot() to use
> in practise in the same way as engineers rarely use single signal
> names to replace equations in if() or elsif()."
>
> I've already told you that you do not need to use single signal names
> with zero_one_hot() arguments anymore than you have to use them with
> if/elsif/orif conditions; expressions can be used in both instances.
> Nor are you limited to using expressions in either place; you can
> assign a signal or variable, which will often be more readable in both
> instances anyway. What "engineers rarely [or commonly] use" is not the
> definition of good coding practice.
>
> zero_one_hot() can always be prefixed with the standard package name
> in which it is defined. Keywords, on the other hand cannot. I believe
> that tricks like '_' and '%' on the front of new keywords are a
> hideous hack, nevertheless befitting this whole orif concept.
>
> Any synthesis tool that cannot figure out the code below (rewritten
> from your example, but in standard vhdl with elsif) indicates mutually
> exclusive conditions should be immediately uninstalled and returned to
> the vendor for a full refund!
>
> if(two_bits =3D "00") then
>   ...
> elsif(two_bits =3D "01") then
>   ...
> elsif(two_bits =3D "10") then
>   ...
> else  <-- equivalent to "when others =3D>"
>   ...
> end if;
>
> As for mutual exclusivity of combinatorial signals or variables, why
> do you think mutual exclusivity should be limited to registers only?
> Even in  your own code examples you have demonstrated mutual
> exclusivity of intermediate ...
>
> read more =BB- Hide quoted text -
>
> - Show quoted text -

Hi Andy and Jim,
I like to discuss the issue further with you.

I have to change my keyword 'orif' definition to make it perfect (it
may need more fine tuning with other's help, no matter what is, I am
not a good protocol writer, but I am learning), but the basic idea has
been the same as before and consistent without any change since March
2002 I published a paper with Jim as the paper's reviewer.

Keyword 'orif' has the same language grammar definition as keyword
'elsif' with one exception: conditional signal contained in leading
keywords 'if()' or 'elsif()' and conditional signals contained in the
subsequent and contiguous keyword 'orif()' at the same level in an
'if...elsif...end if' statement are mutually exclusive. Where keyword
'elsif' can be used in a VHDL code, there keyword 'orif' can be used.
'orif' and 'elsif' can be mixed at any levels of 'if...elsif...end if'
statements.

Here is a better example to show how powerful 'orif' is.

If(E0 =3D '1') then
   If(E01 =3D '1') then
      State_A <=3D E01_S;
   orif(E02 =3D '1') then
      State_A <=3D E02_S;
   orif(E03 =3D '1') then
      State_A <=3D E03_S;

   elsIf(E04 =3D '1') then
      State_A <=3D E04_S;
   end if;
Orif(E1 =3D '1') then
   State_A <=3D E1_S;
Orif(E2 =3D '1') then
   State_A <=3D E2_S;

elsIf(E3 =3D '1') then
   State_A <=3D E3_S;
Orif(E4 =3D '1') then
   If(E41 =3D '1') then
      State_A <=3D E41_S;
   elsif(E42 =3D '1') then
      State_A <=3D E42_S;
   orif(E43 =3D '1') then
      State_A <=3D E43_S;
   orIf(E44 =3D '1') then
      State_A <=3D E44_S;
   end if;

Orif(E5 =3D '1') then
   State_A <=3D E5_S;

elsIf(E6 =3D '1') then
   ...
else
   ...
end if;

Mutually exclusive groups: (E0, E1, E2), (E3, E4, E5), (E01, E02,
E03), (E42, E43, E44).

I would like to add a blank line to separate two groups in order not
to make a confusion with viewers of this post. Personnally I don't
think the blank line is needed if you are used to it.

I would like to tell you my experiences: when you are writing mutually
exclusive conditions, you don't know in advance that those group of
conditional signals that are mutually exclusive are written correctly,
and takes a long way to make them correct. You have to fine turn to
make them mutually exclusive finally.
The process is a slow learning one and you cannot write it immediately
without error. When zero_one_hot() method is used, you have two
choices: write them separately in its defnition area and its calling
area from start, or write them like writing a conventional
'if...eslif...end if' statement, then copy them and call them to
become 2 separate code after you are certain that they are right. I
know you have the experiences to write any 'if...eslif...end if'
statements. First of all, I don't believe you would like to write
'if...eslif...end if' statement in 2 separate parts, one for its
definition and assign statements, another is called in
'if...eslif...end if' statement. Then you can imagine same things and
more difficult things happening with the same situations as writing
'if...eslif...end if' statement.

I can imagine if both methods, Jim's and mine, are introduced into
VHDL standard, I can bet with you: 99.9999% of engineers who use
mutually exclusive method to speed up their designs would use my
method. My basis is nobody who write 'if...eslif...end if' statements
today uses 2 separate parts as Jim suggested for zero_one_hot() to
write 'if...eslif...end if' statements.

I have to point out the following code has error:

if(E0 =3D '1') then
  OutBus(63 downto 0) <=3D Data0(63 downto 0);
orif(E1 =3D '1') then
  OutBus(63 downto 0) <=3D Data1(63 downto 0);
orif(E2 =3D '1') then
  OutBus(63 downto 0) <=3D Data2(63 downto 0);
end if;

Its implementation equation should look like this:
OutBus =3D E0*Data0 + E1*Data1 + E2*Data2 + OutBus;


The correct equation should look like this:
OutBus =3D E0*Data0 + E1*Data1 + E2*Data2 + (not (E0+E1+E2))*OutBus;


Here is Jim's equation that is wrong !
 If(E0 =3D '1') then
      State_A <=3D E0_S;
   Orif(E1 =3D '1') then
      State_A <=3D E_S;
   Orif(E2 =3D '1') then
      State_A <=3D E2_S;
   elsIf(E3 =3D '1') then
      State_A <=3D E3_S;
   Orif(E4 =3D '1') then
      State_A <=3D E4_S;
   Orif(E5 =3D '1') then
      State_A <=3D E5_S;
   elsIf(E6 =3D '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 =3D '1') then
       OutBus <=3D (others=3D>'0');
    elsif rising_edge(CLK) then
       if (E0 or E1 or E2 or E3 or E4 or E5) =3D '1' then
         OutBus <=3D
           (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;

Jim, try this set of values: E0 =3D '1' and E3 =3D '1', you get data:
Data0 or Data3, not Data0.

Weng



Article: 123548
Subject: Where is Command Reg and Status Reg as mentioned in PCI system architecture (Mindshare) in generated pci32 core?
From: Ace <yasirmm@gmail.com>
Date: Wed, 29 Aug 2007 18:54:31 -0700
Links: << >>  << T >>  << A >>
Hi,

I realize that in cfg.vhd files generated by PCI32 LogiCore does not
have command register and status register. From Mindshare book, it
said it is "always mandatory" to supply this information. Does anyone
know what do I need to do/add?


Cheers!


Article: 123549
Subject: Re: altera's USB byteblaster cable: anyone has the mindford one?
From: "Rodo" <dsp1024@yahoo.com>
Date: Thu, 30 Aug 2007 02:46:37 GMT
Links: << >>  << T >>  << A >>
This looks better than the one I was looking at.

Thanks


"Fredrik" <fredrik_he_lang@hotmail.com> wrote in message 
news:1188371048.944664.237480@r29g2000hsg.googlegroups.com...
> Hi Rodo,
> Haven't used that particular one, but I do have used TerAsics clone.
> You can find that one at:
> www.terasic.com.tw (USB Blaster cable).
> Pricing 50$ works as good as the "real" one.
> Regards
> Fredrik
> 





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search