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
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: 123526The 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, VasileArticle: 123527
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
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... > > /MikhailArticle: 123529
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
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, GaborArticle: 123531
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, -- EdmondArticle: 123532
"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. /MikhailArticle: 123533
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? ShadabArticle: 123534
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. > > /MikhailArticle: 123535
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, DanArticle: 123536
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
"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. /MikhailArticle: 123538
there are also UCF lines: NET ctrl_data<*> SLEW = FAST; NET ctrl_data<*> DRIVE = 2; NET ctrl_data<*> IOSTANDARD = LVCMOS33;Article: 123539
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: 123540On 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 DuthArticle: 123541
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 DuthArticle: 123542
:):) 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. > > /MikhailArticle: 123543
"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
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... VasileArticle: 123545
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
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 PeteSArticle: 123547
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: 123548Hi, 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
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:
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