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
"maxascent" <maxascent@yahoo.co.uk> wrote in message news:ifidnQIYxf3YUUvbRVn_vw@giganews.com... > > Hi > > If I am designing a pcb using impedance controlled layers can I treat the > power planes as a reference layer as well as the gnd layers? > > Cheers > > Jon Hi Jon, Yes. But with a caveat. When your signals switch reference layers, make sure there is a path for the reference current. E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal goes from layer 1 to 6 through a via, you should have a bypass cap bewteen power and ground near this via. Think of your signal as differential, the complementary signal being the reference. It's for this reason that I long ago ditched power planes and use multiple ground planes instead. I route and/or copper pour powers. Then the bypass cap in the example I gave can be replaced by a ground via, because layer 5 is ground in my PCB. HTH., Syms.Article: 123576
Weng,
> 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.
So you and I have had some time to discuss and ponder this.
Personally I am worn out and don't have further energy to
afford this issue as I consider it a solved problem.
One of the things that shifted my mind away from "ORIF"
is that there are mutual exclusion problems that it
cannot solve. One you had brought up in a previous
discussion (some time ago) where you had mixed conditions
with some signals mutually exclusive and some not.
I think this is a common case.
Can you post one of the examples you shared with me previously
and explain how this would be handled by "ORIF"?
> I have to point out the following code has error:
...
> Here is Jim's equation that is wrong !
Please use quoting properly as I can't tell your
referenced text from your new thoughts. As a result,
I cannot follow your line of thought at all, so I can't
comment on all of it - it looks like you included too
much text.
I will make an educated guess that this is the example
on which you wanted to comment:
> Also note that if you are using std_logic or bit types, with the
> Accellera VHDL-2006 revision you can write:
> OutBusA : process(RESET, CLK)
> begin
> if(RESET = '1') then
> OutBus <= (others=>'0');
> elsif rising_edge(CLK) then
> if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
> OutBus <=
> (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
> (E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
> end if ;
> end if ;
> end process;
>
> Jim, try this set of values: E0 = '1' and E3 = '1', you get data:
> Data0 or Data3, not Data0.
Please note that your original example for OutBus used all
"orif" and did not mix elsif with orif, so yes there is no
priority between E0 and E3 here and Data0 or Data3 is the
correct answer.
Can "ORIF" also construct the equivalent to the following?
OutBusBProc : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
OutBusB <=
(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 process ;
What compelling real hardware problems does "ORIF" solve
that either are not solved by other methods or are
cumbersome using other methods?
Cheers,
Jim
Article: 123577Colin Paul, > |---------------------------------------------------------------------------------------------| > |" 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. | > |---------------------------------------------------------------------------------------------| > > That would be true for plain VHDL without PSL, but he posted as if > zero_one_hot() is now part of VHDL from PSL (but it is not in my PSL > reference manual, unlike onehot0) so that would not necessarily > require that a VHDL identifier be changed. From the PSL standard: > "[..] > OOPS. I missed that. I had meant to reference the PSL function onehot0. > |---------------------------------------------------------------------------------------------| > |"[..] | > |> zero_one_hot() can always be prefixed with the standard package name | > |> in which it is defined." | > |---------------------------------------------------------------------------------------------| > > Andy, > > Is zero_one_hot() defined in a package? Even if it is, Weng was > complaining that Jim complained that orif would clash with a > basic_identifier and Weng perceived this as hypocrisy as he thought > zero_one_hot() would also clash with a basic_identifier. Reserved words have more strength than subprogram names. I would have to double check, but I think that if you re-use a subprogram name as a signal name in a design, the subprogram name becomes hidden and can only be referenced with a fully selected name. For old designs that do not use the subprogram, this is ok (or exactly the behavior you desire). In new designs, this situation is easy to avoid. If two packages are referenced with the same subprogram name, then the subprograms are homographs and neither can be directly referenced and as a result can only be referenced with a fully selected name. So there is some concern with this, however, it is not a difficult one for a user to address. While it is possible that syntax could be given a similar interpretation, I am not sure it would be a good thing. Cheers, JimArticle: 123578
On Aug 30, 10:14 am, EEngineer <mari...@gmail.com> wrote: > On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote: > > > > > On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > > > > "EEngineer" <mari...@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. > > > If you need your outputs to have very low skew, your only hope > > is to place all of the output flip-flops in the IOB's (IOB=TRUE > > attribute on the flip-flop or net). You can also globally place > > registers in IOB's using the synthesis and map properties. If > > your outputs are generated by fabric flip-flops it is very hard > > to get your skew below 2.5 nS > > > By the way, why do you need such low skew on these lines? Is the > > driven device asynchronous with respect to your clock? > > > Regards, > > Gabor > > I need those signals to control the analog CMOS circuit that has a > requirement for some signals not to overlap - this happens when the > output from the FPGA is not synchronous enough. These signals will never be "synchronous enough" to guarantee zero overlap when changing on the same clock cycle. Use a faster clock if you need to, but certainly add a clock cycle between assertion of signals that must not overlap.Article: 123579
I am using a XUP development board for my project. It is this one: http://www.digilentinc.com/Products/Detail.cfm?Nav1=Products&Nav2=Programmable&Prod=XUPV2P I want to reconfigure this board from a second board (same one). The configuration stream is stored in the DDR RAM of the second board. My problem is, that I cannot find a way to transfer the data into the flash memory of the first board. The documentation says, that there are 3 ways for configuration: 1) Flash card (can't use it in this case) 2) via USB JTAG port (the second board would need an USB host port but these boards are equipped with an USB client port only) 3) via PC4 cable (no idea how this works) Normally the solutions 2 and 3 are done with Xilinx' IMPACT software. Since I don't have this software on the second board, this seems to be a problem, because I do not know, how this software works. I have also checked the layout of the board. I looks like the Boundary Scan pins TMS, TCK and TDO are connected to the J6 interface (GPIOs). The problem is - where is TDI? The schematics PDF only shows a FPGA_TDI connection between the FPGA and the System Ace. It does not seem to be connected to a GPIO. Has anyone already tried to configure such a board without using a PC and IMPACT? How did you realize that? Thanks in advance Sebastian GollerArticle: 123580
On aug. 30, 16:20, emu <e...@ecubics.com> wrote: > On Aug 30, 7:14 am, dormanpet...@gmail.com wrote: > > > Hello! > > > I would like to change the FPGA in this board to a bigger one, but I > > don't know if it's possible. > > Why are you not just buying the bigger one with the xc3s1600e ? Because in Hungary I cannot buy that board, and it would be cheaper for me to change it instead of buying a new one... (I'm just a student)Article: 123581
On Aug 30, 9:41 am, Gabor <ga...@alacron.com> wrote: > On Aug 30, 4:59 am, Guru <ales.gor...@email.si> wrote: > > > > > Hi all, > > > We are building a board with Spartan3E (XC3S1200E FG320) and a 64MB > > x16 DDR (HYB25DC512160CF-6). Trying to make the board as tiny as > > possible the DDR termination presents a problem. Since the Spartan3E > > does not have DCI, termination on chip is not possible. This means > > that 44 termination resistors should be added and maybe a VTT power > > source. The other problem is that according to MIG we should connect > > DDR to two banks. > > > Any good suggestions? > > Is it possible to eliminate termination resistors? > > > Cheers, > > > Guru > > If you're only driving a single chip with very short lines you > can probably get away without termination on everything except > the clock. I would suggest using SSTL2_I instead of SSTL2_II > to avoid overdriving. Another approach is to just leave out > the series termination on these signals and just add the parallel > termination to Vtt. I've used the latter method with Virtex2 > and an SO-DIMM without DCI on the data lines and SSTL2_I drive. > A good argument for leaving out the series termination is any > net where the driving stub (from the S3 to the resistor) is > about the same length as the driven stub (from the resistor > to the memory). Here the terminator is of dubious value. > > It's probably best to simulate your transmission lines, > especially if you're planning to run the memory at its > maximum speed of 166 MHz / DDR333. My V2 design ran at > 133 MHz / DDR266. > > HTH, > Gabor One other thought if your main interest is in reducing the board size. Often I find that using a x32 single-data-rate (143 MHz) memory can save space. If you're using a TSSOP-66 package for the DDR part, the 86-pin TSSOP for the x32 SDR part has the same footprint and runs from +3.3V with no requirements for VREF and DQS pins on the FPGA and no Vtt or 2.5V supply. So unless you already had the 2.5V supply for another reason you could save space, and depending on the number of Vref pins eaten up by the SSTL2 I/O standard, you may not add significantly more I/O pins to the design.Article: 123582
On Aug 30, 11:17 am, Sebastian Goller <s...@hrz.tu-chemnitz.de> wrote: > I am using a XUP development board for my project. It is this one: > > http://www.digilentinc.com/Products/Detail.cfm?Nav1=Products&Nav2=Pro... > > I want to reconfigure this board from a second board (same one). The > configuration stream is stored in the DDR RAM of the second board. My > problem is, that I cannot find a way to transfer the data into the > flash memory of the first board. The documentation says, that there > are 3 ways for configuration: > > 1) Flash card (can't use it in this case) > 2) via USB JTAG port (the second board would need an USB host port but > these boards are equipped with an USB client port only) > 3) via PC4 cable (no idea how this works) > > Normally the solutions 2 and 3 are done with Xilinx' IMPACT software. > Since I don't have this software on the second board, this seems to be > a problem, because I do not know, how this software works. > > I have also checked the layout of the board. I looks like the Boundary > Scan pins TMS, TCK and TDO are connected to the J6 interface (GPIOs). > The problem is - where is TDI? The schematics PDF only shows a > FPGA_TDI connection between the FPGA and the System Ace. It does not > seem to be connected to a GPIO. > > Has anyone already tried to configure such a board without using a PC > and IMPACT? How did you realize that? > > Thanks in advance > > Sebastian Goller Anything you can configure from iMPACT with the parallel cable can be configured from another source. TDI must connect to the FPGA via the JTAG scan chain for iMPACT to work. The simplest way to store data for programming would be to create an xsvf file using iMPACT. Then use the standard embedded code for programming with 2nd board via JTAG. The existence of additional parts in the JTAG scan chain should not be a problem as long as you properly identify the chain components when you create the xsvf file. If you had access to the serial programming pins of the FPGA on the 2nd board (CCLK DIN PROG INIT DONE) you could easily just use the bitstream without needing an svf or xsvf file. Slave serial programming is very simple in this case. HTH, GaborArticle: 123583
On Aug 30, 6:00 am, fazulu deen <fazulu.v...@gmail.com> wrote: > Jon Beniston wrote: > > On 30 Aug, 10:21, fazulu deen <fazulu.v...@gmail.com> wrote: > > > Hai all, > > > > Can any one suggest with an example how to run c++ code in modelsim > > > simulator...I didnt understand the example mentioned in modelsim user > > > guide..Anyone tried this?? > > > What didn't you understand about it? > > >linking was not clear to me and also in my case while simulating the c++ it will output a test file that has be red by the verilog code...both c++ and verilog is independent and c++ should be first before verilog after the file is obtained from the c++ simulator the verilog will start....how this can be achieved Fazulu, If I understand you want to fire-off a thread in C++ and then invoke the verilog in msim. While I am not sure this could be done but I think for all practical purposes you can model your system so that your logic design (verilog sim) starts first and then invokes C++ routines that comprise your system environment. I followed the commands and guidelines shown in msim's documentation for visual c. And that worked for me. What did not work was the cygwin commands they had listed. -sanjayArticle: 123584
On Aug 30, 12:22 pm, "Symon" <symon_bre...@hotmail.com> wrote:
> However, this is _NOT_ true in this case. The signal EN, which is high for
> one in every four cycles of the clock, is gated into this logic that makes
> CNT_EN. Whenever EN is low, the signal CNT_CE is low, no matter what the CNT
> signals are. So, as long as the signal EN gets from the FF it's generated in
> to CNT_EN and the CE pins of the CNT counter, all will be well, provided the
> CNT signals get through the logic by the time the EN signal next goes high.
Let's now assume that the CNT_CE is made by a single 4-input LUT. One
of those inputs is the EN itself, so when EN=0 the output, according
to the LUT's logic mapping, is indeed 0. But the other three input can
go crazy during these four cycles.
Now, can this cause glitches or not? As far as I know, the LUT's spec
guarantees a propagation delay after all inputs are stable. Does it
say anything about transactions between two 4-input sets, which give
the same output value anyhow? After all, a LUT is a 16x1 bit RAM. Is
there any guarantee that its output stays steady at 0 when EN=0. An
AND port would, but what do we know about the LUT?
The simulation won't show this, of course, because the simulation
model for a LUT merely shows the propagation delay.
Now, you need some bad luck to sample the CE exactly when it's
glitching, so the fact that multi-cycle paths commonly work as is,
doesn't mean that we have our bottoms covered.
If someone can turn me to where Xilinx guarantees a stable output from
a LUT, when three inputs change, and one remains stable, so that there
is no reason to change the output -- I'll be relieved to see it.
Thanks,
Eli
Article: 123585Dear When I look at Virtex-II Pro data sheet (DS083 v. 4.5), page 7, I see following table. ------------------------- Package FF896 Pitch (mm) 1.00 Size (mm) 31 x 31 ------------------------- I guess that Distance between neighbor pins = 1 mm Die size = 31 mm x 31 mm Could someone explain this? Am I correct?Article: 123586
On Aug 29, 1:35 pm, Edmond Cot=E9 <edmond.c...@gmail.com> wrote: > 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 Besides the performance there is a benefit of routing as well. You can place your modules farther from the memory blocks. You may have to do this if say you are driving external i/os from the same block that is also accessing the internal ram block. -sanjayArticle: 123587
On Aug 30, 9:10 pm, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote: > On Aug 30, 6:00 am, fazulu deen <fazulu.v...@gmail.com> wrote: > > > Jon Beniston wrote: > > > On 30 Aug, 10:21, fazulu deen <fazulu.v...@gmail.com> wrote: > > > > Hai all, > > > > > Can any one suggest with an example how to run c++ code in modelsim > > > > simulator...I didnt understand the example mentioned in modelsim user > > > > guide..Anyone tried this?? > > > > What didn't you understand about it? > > > >linking was not clear to me and also in my case while simulating the c++ it will output a test file that has be red by the verilog code...both c++ and verilog is independent and c++ should be first before verilog after the file is obtained from the c++ simulator the verilog will start....how this can be achieved > > Fazulu, > > If I understand you want to fire-off a thread in C++ and then invoke > the verilog in msim. While I am not sure this could be done but I > think for all practical purposes you can model your system so that > your logic design (verilog sim) starts first and then invokes C++ > routines that comprise your system environment. I followed the > commands and guidelines shown in msim's documentation for visual c. > And that worked for me. What did not work was the cygwin commands > they had listed. > > -sanjay Hai sanjay, Exactly you r correct....but did u heard about qverilog command it is close to my requirement..... But still i dont know how to invoke it.. regards, fazalArticle: 123588
<eli.billauer@gmail.com> wrote in message news:1188490254.596804.226250@o80g2000hse.googlegroups.com... > On Aug 30, 12:22 pm, "Symon" <symon_bre...@hotmail.com> wrote: > >> However, this is _NOT_ true in this case. The signal EN, which is high >> for >> one in every four cycles of the clock, is gated into this logic that >> makes >> CNT_EN. Whenever EN is low, the signal CNT_CE is low, no matter what the >> CNT >> signals are. So, as long as the signal EN gets from the FF it's generated >> in >> to CNT_EN and the CE pins of the CNT counter, all will be well, provided >> the >> CNT signals get through the logic by the time the EN signal next goes >> high. > > Let's now assume that the CNT_CE is made by a single 4-input LUT. One > of those inputs is the EN itself, so when EN=0 the output, according > to the LUT's logic mapping, is indeed 0. But the other three input can > go crazy during these four cycles. > > Now, can this cause glitches or not? As far as I know, the LUT's spec > guarantees a propagation delay after all inputs are stable. Does it > say anything about transactions between two 4-input sets, which give > the same output value anyhow? After all, a LUT is a 16x1 bit RAM. Is > there any guarantee that its output stays steady at 0 when EN=0. An > AND port would, but what do we know about the LUT? > > The simulation won't show this, of course, because the simulation > model for a LUT merely shows the propagation delay. > > Now, you need some bad luck to sample the CE exactly when it's > glitching, so the fact that multi-cycle paths commonly work as is, > doesn't mean that we have our bottoms covered. > > If someone can turn me to where Xilinx guarantees a stable output from > a LUT, when three inputs change, and one remains stable, so that there > is no reason to change the output -- I'll be relieved to see it. > > Thanks, > Eli > Hi Eli, OK, great you've sussed it! And no, the LUTs don't glitch. The LUTs are made of a tree of MUXes which select one of sixteen configuration bits. If the input EN signal is '0', all the thrashing in the world on the other inputs should have no effect, because the EN input guarantees the LUT to be selecting a '0' configuration bit. See http://direct.xilinx.com/bvdocs/appnotes/xapp024.pdf for XC3000 series, not exactly up to date, but backs up what I'm saying about muxes. Peter Alfke at Xilinx is a good guy to confirm this with, and I'd be grateful if you could let me know if he contradicts what I say, or the syn_direct_enable will become a necessity. You can find his email by searching this newsgroup. Oh, I found it! Search google groups CAF for a thread called " Xilinx LUT behavior question" where Peter confirms this mode of operation. He says "I have answered this particular question many times over the past 15 years." Cheers, Syms. p.s. At least I bet you learnt a whole lot of useful stuff about constraints in the last fortnight! This'll certainly serve you well in the future. :-)Article: 123589
"Symon" <symon_brewer@hotmail.com> wrote in message news:fb6sms$bbd$1@aioe.org... > > Oh, I found it! Search google groups CAF for a thread called " Xilinx LUT > behavior question" where Peter confirms this mode of operation. He says "I > have answered this particular question many times over the past 15 years." > I wish I hadn't suggested that thread. My 'clever dick' response to Eric is not relevant in the case brought up in this thread. Live and learn! Syms.Article: 123590
On Aug 30, 7:46 am, Jim Lewis <j...@synthworks.com> wrote:
> Weng,
> > 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.
>
> So you and I have had some time to discuss and ponder this.
>
> Personally I am worn out and don't have further energy to
> afford this issue as I consider it a solved problem.
>
> One of the things that shifted my mind away from "ORIF"
> is that there are mutual exclusion problems that it
> cannot solve. One you had brought up in a previous
> discussion (some time ago) where you had mixed conditions
> with some signals mutually exclusive and some not.
> I think this is a common case.
> Can you post one of the examples you shared with me previously
> and explain how this would be handled by "ORIF"?
>
> > I have to point out the following code has error:
> ...
> > Here is Jim's equation that is wrong !
>
> Please use quoting properly as I can't tell your
> referenced text from your new thoughts. As a result,
> I cannot follow your line of thought at all, so I can't
> comment on all of it - it looks like you included too
> much text.
>
> I will make an educated guess that this is the example
> on which you wanted to comment:
>
>
>
>
>
> > Also note that if you are using std_logic or bit types, with the
> > Accellera VHDL-2006 revision you can write:
> > OutBusA : process(RESET, CLK)
> > begin
> > if(RESET = '1') then
> > OutBus <= (others=>'0');
> > elsif rising_edge(CLK) then
> > if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
> > OutBus <=
> > (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
> > (E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
> > end if ;
> > end if ;
> > end process;
>
> > Jim, try this set of values: E0 = '1' and E3 = '1', you get data:
> > Data0 or Data3, not Data0.
>
> Please note that your original example for OutBus used all
> "orif" and did not mix elsif with orif, so yes there is no
> priority between E0 and E3 here and Data0 or Data3 is the
> correct answer.
>
> Can "ORIF" also construct the equivalent to the following?
> OutBusBProc : process(RESET, CLK)
> begin
> if(RESET = '1') then
> OutBus <= (others=>'0');
> elsif rising_edge(CLK) then
> OutBusB <=
> (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 process ;
>
> What compelling real hardware problems does "ORIF" solve
> that either are not solved by other methods or are
> cumbersome using other methods?
>
> Cheers,
> Jim- Hide quoted text -
>
> - Show quoted text -
Hi Jim,
Simply say, there are several ways to specify that a group of signals
is mutually exclusive.
In other words, there are several ways to do the same things. Now the
question is which is best one to be chosen as part of standard of
VHDL.
The differences between your way and mine are as follows:
1a. Your way advantage
Your function name zero_one_hot() can be more compatible with same old
function zero_one_hot(). But you admit there are still problems over
there and you promise it is not a big problem.
1b. You way disadvantage:
it must be done off-line with 2N+1 extra lines to do the same things:
N signal declaration lines;
N assign statements to new signals
1 assertion call statement.
2a. My way advantages are
a. It provides on-line programming capability.
b. It provides a unified language branch statement structure by mixing
'elsif' and 'orif'.
2b. Keyword 'orif' would conflict other old signal name orif users
might have had used.
I am not sure Colin has proved that it can be avoid or not. In this
respect I would like other experts' help to determine it or resolve
it.
>From the following code segment provided by Marcus,
Verilog uses new keyword 'unique' to provide on-line programming
capability to specify mutually exclusiveness.
| module unique_if;
| bit clk, reset;
|
| logic E0, E1, E2, E3, E4, E5;
| logic [0:5] E;
|
| logic [7:0] OutBus;
| logic [7:0] Data [0:5] = '{ 0, 1, 2, 3, 4, 5 };
|
|
| initial begin
| clk <= 0;
| reset <= 1;
| #20ns;
| reset <= 0;
| end
|
| always clk = #5ns ~clk;
|
| always @(posedge clk, posedge reset) begin
| if(reset)
| OutBus <= 0;
| else begin
| void'(randomize(E) with {
| E inside { 1, 2, 4, 8, 16, 32, 10 }; // note the
occurence of 10
| });
|
| {E0, E1, E2, E3, E4, E5} = E;
|
| unique if(E0) OutBus <= Data[0];
| else if(E1) OutBus <= Data[1];
| else if(E2) OutBus <= Data[2];
| else if(E3) OutBus <= Data[3];
| else if(E4) OutBus <= Data[4];
| else if(E5) OutBus <= Data[5];
| end
| end
|
| endmodule : unique_if
I don't know if Verilog provides the same function zero_one_hot().
As far as 'orif' is concernd, I would like to ask why 'orif' name
conflict problem is so serious?
In my experiences, I have met more consistency problems between two
VHDL versions about unsigned, std_logic_vec, ... and very confused and
I don't know how to listen to which experts's ideas.
For example, for 200x VHDL version, a new keyword 'orif' will be
added, then you must check if your old design has the words, and
if ...
Is it not enough? Or is it troubled enough to make confusion as large
as unsigned, std_logic_vec, ...?
I will re-post my encoding with 'orif' posted two years ago as Jim
asked.
Weng
Article: 123591
Pasacco <pasacco@gmail.com> wrote:
> Dear
> When I look at Virtex-II Pro data sheet (DS083 v. 4.5), page 7,
> I see following table.
> -------------------------
> Package FF896
> Pitch (mm) 1.00
> Size (mm) 31 x 31
> -------------------------
> I guess that
> Distance between neighbor pins = 1 mm
^^^^
Substitute oins with balls
> Die size = 31 mm x 31 mm
^^^
Substitute die with package.
The die should be substantial smaller or else
the IC would be much more expensive
> Could someone explain this?
> Am I correct?
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Article: 123592On Aug 30, 11:12 am, Gabor <ga...@alacron.com> wrote: > On Aug 30, 10:14 am, EEngineer <mari...@gmail.com> wrote: > > > > > On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote: > > > > On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > > > > > "EEngineer" <mari...@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. > > > > If you need your outputs to have very low skew, your only hope > > > is to place all of the output flip-flops in the IOB's (IOB=TRUE > > > attribute on the flip-flop or net). You can also globally place > > > registers in IOB's using the synthesis and map properties. If > > > your outputs are generated by fabric flip-flops it is very hard > > > to get your skew below 2.5 nS > > > > By the way, why do you need such low skew on these lines? Is the > > > driven device asynchronous with respect to your clock? > > > > Regards, > > > Gabor > > > I need those signals to control the analog CMOS circuit that has a > > requirement for some signals not to overlap - this happens when the > > output from the FPGA is not synchronous enough. > > These signals will never be "synchronous enough" to guarantee zero > overlap when changing on the same clock cycle. Use a faster clock > if you need to, but certainly add a clock cycle between assertion > of signals that must not overlap. Yes, I was thinking of using 16 times faster clock to add one clock cycle in between, but I have checked signals with the 500MHz scope (10Mohm, 9.5pF probes) and it looks like that digital analyser is giving misleading waveforms - there is almost no delay between these two signals (less then 1ns). The rise time is same for both signals, and this can be improved by increasing the drive in UCF file from the minimum 2mA, I don't know the load yet.Article: 123593
On Aug 30, 10:08 am, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Aug 30, 7:46 am, Jim Lewis <j...@synthworks.com> wrote:
>
>
>
>
>
> > Weng,
> > > 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.
>
> > So you and I have had some time to discuss and ponder this.
>
> > Personally I am worn out and don't have further energy to
> > afford this issue as I consider it a solved problem.
>
> > One of the things that shifted my mind away from "ORIF"
> > is that there are mutual exclusion problems that it
> > cannot solve. One you had brought up in a previous
> > discussion (some time ago) where you had mixed conditions
> > with some signals mutually exclusive and some not.
> > I think this is a common case.
> > Can you post one of the examples you shared with me previously
> > and explain how this would be handled by "ORIF"?
>
> > > I have to point out the following code has error:
> > ...
> > > Here is Jim's equation that is wrong !
>
> > Please use quoting properly as I can't tell your
> > referenced text from your new thoughts. As a result,
> > I cannot follow your line of thought at all, so I can't
> > comment on all of it - it looks like you included too
> > much text.
>
> > I will make an educated guess that this is the example
> > on which you wanted to comment:
>
> > > Also note that if you are using std_logic or bit types, with the
> > > Accellera VHDL-2006 revision you can write:
> > > OutBusA : process(RESET, CLK)
> > > begin
> > > if(RESET = '1') then
> > > OutBus <= (others=>'0');
> > > elsif rising_edge(CLK) then
> > > if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
> > > OutBus <=
> > > (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
> > > (E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
> > > end if ;
> > > end if ;
> > > end process;
>
> > > Jim, try this set of values: E0 = '1' and E3 = '1', you get data:
> > > Data0 or Data3, not Data0.
>
> > Please note that your original example for OutBus used all
> > "orif" and did not mix elsif with orif, so yes there is no
> > priority between E0 and E3 here and Data0 or Data3 is the
> > correct answer.
>
> > Can "ORIF" also construct the equivalent to the following?
> > OutBusBProc : process(RESET, CLK)
> > begin
> > if(RESET = '1') then
> > OutBus <= (others=>'0');
> > elsif rising_edge(CLK) then
> > OutBusB <=
> > (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 process ;
>
> > What compelling real hardware problems does "ORIF" solve
> > that either are not solved by other methods or are
> > cumbersome using other methods?
>
> > Cheers,
> > Jim- Hide quoted text -
>
> > - Show quoted text -
>
> Hi Jim,
> Simply say, there are several ways to specify that a group of signals
> is mutually exclusive.
>
> In other words, there are several ways to do the same things. Now the
> question is which is best one to be chosen as part of standard of
> VHDL.
>
> The differences between your way and mine are as follows:
> 1a. Your way advantage
> Your function name zero_one_hot() can be more compatible with same old
> function zero_one_hot(). But you admit there are still problems over
> there and you promise it is not a big problem.
>
> 1b. You way disadvantage:
> it must be done off-line with 2N+1 extra lines to do the same things:
> N signal declaration lines;
> N assign statements to new signals
> 1 assertion call statement.
>
> 2a. My way advantages are
> a. It provides on-line programming capability.
> b. It provides a unified language branch statement structure by mixing
> 'elsif' and 'orif'.
>
> 2b. Keyword 'orif' would conflict other old signal name orif users
> might have had used.
> I am not sure Colin has proved that it can be avoid or not. In this
> respect I would like other experts' help to determine it or resolve
> it.
>
> >From the following code segment provided by Marcus,
>
> Verilog uses new keyword 'unique' to provide on-line programming
> capability to specify mutually exclusiveness.
>
> | module unique_if;
> | bit clk, reset;
> |
> | logic E0, E1, E2, E3, E4, E5;
> | logic [0:5] E;
> |
> | logic [7:0] OutBus;
> | logic [7:0] Data [0:5] = '{ 0, 1, 2, 3, 4, 5 };
> |
> |
> | initial begin
> | clk <= 0;
> | reset <= 1;
> | #20ns;
> | reset <= 0;
> | end
> |
> | always clk = #5ns ~clk;
> |
> | always @(posedge clk, posedge reset) begin
> | if(reset)
> | OutBus <= 0;
> | else begin
> | void'(randomize(E) with {
> | E inside { 1, 2, 4, 8, 16, 32, 10 }; // note the
> occurence of 10
> | });
> |
> | {E0, E1, E2, E3, E4, E5} = E;
> |
> | unique if(E0) OutBus <= Data[0];
> | else if(E1) OutBus <= Data[1];
> | else if(E2) OutBus <= Data[2];
> | else if(E3) OutBus <= Data[3];
> | else if(E4) OutBus <= Data[4];
> | else if(E5) OutBus <= Data[5];
> | end
> | end
> |
> | endmodule : unique_if
>
> I don't know if Verilog provides the same function zero_one_hot().
>
> As far as 'orif' is concernd, I would like to ask why 'orif' name
> conflict problem is so serious?
>
> In my experiences, I have met more consistency problems between two
> VHDL versions about unsigned, std_logic_vec, ... and very confused and
> I don't know how to listen to which experts's ideas.
>
> For example, for 200x VHDL version, a new keyword 'orif' will be
> added, then you must check if your old design has the words, and
> if ...
> Is it not enough? Or is it troubled enough to make confusion as large
> as unsigned, std_logic_vec, ...?
>
> I will re-post my encoding with 'orif' posted two years ago as Jim
> asked.
>
> Weng- Hide quoted text -
>
> - Show quoted text -
Hi Jim:
1. Your previous coding has error.
"Please note that your original example for OutBus used all
"orif" and did not mix elsif with orif,"
Please check my first posting over there and it mixes the use of
'orif' and 'elsif' starting from the first posting and it never uses
keyword 'orif' only.
And your coding example is directly copied from your first post on
this thread without any change.
You wrote two assertion statements to show your assertion statement
ability, but coding is wrong. You never wrote a assertion that
includes 6 signals from E0 to E5, but your coding was based on it. It
is a little error not affecting out discussions.
2. Jim asked:
Can "ORIF" also construct the equivalent to the following?
OutBusBProc : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
OutBusB <=
(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 process ;
Here is the answer:
A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if(E0 = '1') then
OutBus <= Data0;
orif(E1 = '1') then
OutBus <= Data1;
orif(E0 = '1') then
OutBus <= Data2;
orif(E0 = '1') then
OutBus <= Data3;
orif(E0 = '1') then
OutBus <= Data4;
orif(E0 = '1') then
OutBus <= Data5;
else
OutBus <= Zero_64;
end if;
end if;
end process;
"ORIF' can not only do the above as an beginner would like to do, but
also do the following equations you showed before more efficiently:
-- assert zero_one_hot (E0, E1, E2) ; -- Jim wrote
-- assert zero_one_hot (E3, E4, E5) ;
assert zero_one_hot (E0, E1, E2, E3, E4, E5) ; -- Weng adds this line
to make code correct
-- It is Jim's coding
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;
I don't know which VHDL version permits the operation: (E0 and Data0),
even though It is not a problem here
-- It is my coding
A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if(E0 = '1') then
OutBus <= Data0;
orif(E1 = '1') then
OutBus <= Data1;
orif(E2 = '1') then
OutBus <= Data2;
orif(E3 = '1') then
OutBus <= Data3;
orif(E4 = '1') then
OutBus <= Data4;
orif(E5 = '1') then
OutBus <= Data5;
else
OutBus <= OutBus;
end if;
end if;
end process;
The above equation would be implemented in Xilinx chip with carry
chain with initial input data to the carry chain being OutBus. The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'
It is not a LUT or two saving as some suggesed. For a up to 400MHz
project, every extra logic would kill a design. Because it takes more
route resources. When route resources exhausted, the running frequency
would drop dramatically and would kill a otherwise successfu design.
LUT is less than a cent in a FPGA.
The above two example show that with mixed 'elsif' and 'orif' language
branch statement structure, HDL will provide more powerful and concise
way to deal with mutually exclusiveness, especially for VHDL
beginners. VHDL beginner would need to go a long way to write the code
type Jim had written.
Weng
Article: 123594Weng, Note the working group is staffed by volunteers. Initial proposals are ranked. If they rank high enough, they get passed to the extensions group. There if someone is interested in championing a proposal, it gets worked on. Without a champion, the proposal gets no where - even if it is something really good - ie: people do not have to work on things. What the group tries to do first is to consider issues and not consider solutions. The person championing a proposal in fact, can either pick up the proposed solution or go in a direction that they think solves the problem. My advice to you is to write a paper that is composed of two sections: Part 1: Identify the problem you are trying to solve. Since this is hardware centric, it would be appropriate to show schematics or block diagrams and code. With respect to the code, there should be several examples. Part 2: Explain how your proposed solution solves the problems at hand and why it is as good as or better than other solutions. Show what it fails to do. So far, I have not seen anything there that would warrant me investing more time in it, however, with your additional input in the form of a paper, may help. Note, the most current revision of VHDL that is ready for vendor adoption is the Accellera draft 3.0, VHDL-2006. This revision includes PSL which includes the onehot0 built-in function (thanks to Colin Paul for the correction). So you would need to show what it does beyond what is currently available. Cheers, JimArticle: 123595
Hello, Silicon Blue Technologies is an FPGA startup located in Sunnyvale CA. The FPGA product it is developing has ultra low power consumption and is targeted to low power applications. The company is seeking some commercial designs in the form of Verilog and/or VHDL designs to test its software and FPGA architecture. Please provide your input if you are interested in the product or have testcases which can be useful to test both FPGA hardware and software capabilities. Thank you. Silicon Blue Technologies http://www.siliconbluetech.comArticle: 123596
comp.arch.fpga wrote:
> The following code has the same semantics:
> if E1 + E2 + E3 > 1 then -- (Lazy and incorrect VHDL type handling to
> shorten example, you will get the point)
> result <= (others => '-');
> elsif E1 = '1' then
> result <= input1;
> elsif E2 = '1' then
> result <= input2;
> elsif E3 = '1' then
> result <= input3;
> else
> result <= (others => '0');
> end if;
This clarifies these long discussions for me.
> In most contexts verification is a far bigger problem then efficient
> implementation.
I couldn't agree more.
> If you really want the most efficient implemetation you should specify
> the detailed behaviour.
> assert (PSL formulation to guarentee mutual exclusiveness goes here);
> result <= (input1 and (result'range => E1) or (input2 and
> (result'range => E2) or (input3 and (result'range => E3);
I agree.
I should describe what I care about,
not what I don't care about.
This simplicity eliminates confusion.
> Telling the synthesis tool to implement wide ORs in carry chains is
> simpler than to introduce a new keyboard.
> This way other uses of wide ORs benefit aswell, as do users of other
> languages.
Yes.
I like to keep the logic description separate
from the device and tool options.
-- Mike Treseler
Article: 123597
On Aug 30, 12:43 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Aug 30, 10:08 am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
>
>
> > On Aug 30, 7:46 am, Jim Lewis <j...@synthworks.com> wrote:
>
> > > Weng,
> > > > 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 Ma=
rch
> > > > 2002 I published a paper with Jim as the paper's reviewer.
>
> > > So you and I have had some time to discuss and ponder this.
>
> > > Personally I am worn out and don't have further energy to
> > > afford this issue as I consider it a solved problem.
>
> > > One of the things that shifted my mind away from "ORIF"
> > > is that there are mutual exclusion problems that it
> > > cannot solve. One you had brought up in a previous
> > > discussion (some time ago) where you had mixed conditions
> > > with some signals mutually exclusive and some not.
> > > I think this is a common case.
> > > Can you post one of the examples you shared with me previously
> > > and explain how this would be handled by "ORIF"?
>
> > > > I have to point out the following code has error:
> > > ...
> > > > Here is Jim's equation that is wrong !
>
> > > Please use quoting properly as I can't tell your
> > > referenced text from your new thoughts. As a result,
> > > I cannot follow your line of thought at all, so I can't
> > > comment on all of it - it looks like you included too
> > > much text.
>
> > > I will make an educated guess that this is the example
> > > on which you wanted to comment:
>
> > > > 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 dat=
a:
> > > > Data0 or Data3, not Data0.
>
> > > Please note that your original example for OutBus used all
> > > "orif" and did not mix elsif with orif, so yes there is no
> > > priority between E0 and E3 here and Data0 or Data3 is the
> > > correct answer.
>
> > > Can "ORIF" also construct the equivalent to the following?
> > > OutBusBProc : process(RESET, CLK)
> > > begin
> > > if(RESET =3D '1') then
> > > OutBus <=3D (others=3D>'0');
> > > elsif rising_edge(CLK) then
> > > OutBusB <=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 process ;
>
> > > What compelling real hardware problems does "ORIF" solve
> > > that either are not solved by other methods or are
> > > cumbersome using other methods?
>
> > > Cheers,
> > > Jim- Hide quoted text -
>
> > > - Show quoted text -
>
> > Hi Jim,
> > Simply say, there are several ways to specify that a group of signals
> > is mutually exclusive.
>
> > In other words, there are several ways to do the same things. Now the
> > question is which is best one to be chosen as part of standard of
> > VHDL.
>
> > The differences between your way and mine are as follows:
> > 1a. Your way advantage
> > Your function name zero_one_hot() can be more compatible with same old
> > function zero_one_hot(). But you admit there are still problems over
> > there and you promise it is not a big problem.
>
> > 1b. You way disadvantage:
> > it must be done off-line with 2N+1 extra lines to do the same things:
> > N signal declaration lines;
> > N assign statements to new signals
> > 1 assertion call statement.
>
> > 2a. My way advantages are
> > a. It provides on-line programming capability.
> > b. It provides a unified language branch statement structure by mixing
> > 'elsif' and 'orif'.
>
> > 2b. Keyword 'orif' would conflict other old signal name orif users
> > might have had used.
> > I am not sure Colin has proved that it can be avoid or not. In this
> > respect I would like other experts' help to determine it or resolve
> > it.
>
> > >From the following code segment provided by Marcus,
>
> > Verilog uses new keyword 'unique' to provide on-line programming
> > capability to specify mutually exclusiveness.
>
> > | module unique_if;
> > | bit clk, reset;
> > |
> > | logic E0, E1, E2, E3, E4, E5;
> > | logic [0:5] E;
> > |
> > | logic [7:0] OutBus;
> > | logic [7:0] Data [0:5] =3D '{ 0, 1, 2, 3, 4, 5 };
> > |
> > |
> > | initial begin
> > | clk <=3D 0;
> > | reset <=3D 1;
> > | #20ns;
> > | reset <=3D 0;
> > | end
> > |
> > | always clk =3D #5ns ~clk;
> > |
> > | always @(posedge clk, posedge reset) begin
> > | if(reset)
> > | OutBus <=3D 0;
> > | else begin
> > | void'(randomize(E) with {
> > | E inside { 1, 2, 4, 8, 16, 32, 10 }; // note the
> > occurence of 10
> > | });
> > |
> > | {E0, E1, E2, E3, E4, E5} =3D E;
> > |
> > | unique if(E0) OutBus <=3D Data[0];
> > | else if(E1) OutBus <=3D Data[1];
> > | else if(E2) OutBus <=3D Data[2];
> > | else if(E3) OutBus <=3D Data[3];
> > | else if(E4) OutBus <=3D Data[4];
> > | else if(E5) OutBus <=3D Data[5];
> > | end
> > | end
> > |
> > | endmodule : unique_if
>
> > I don't know if Verilog provides the same function zero_one_hot().
>
> > As far as 'orif' is concernd, I would like to ask why 'orif' name
> > conflict problem is so serious?
>
> > In my experiences, I have met more consistency problems between two
> > VHDL versions about unsigned, std_logic_vec, ... and very confused and
> > I don't know how to listen to which experts's ideas.
>
> > For example, for 200x VHDL version, a new keyword 'orif' will be
> > added, then you must check if your old design has the words, and
> > if ...
> > Is it not enough? Or is it troubled enough to make confusion as large
> > as unsigned, std_logic_vec, ...?
>
> > I will re-post my encoding with 'orif' posted two years ago as Jim
> > asked.
>
> > Weng- Hide quoted text -
>
> > - Show quoted text -
>
> Hi Jim:
> 1. Your previous coding has error.
> "Please note that your original example for OutBus used all
> "orif" and did not mix elsif with orif,"
> Please check my first posting over there and it mixes the use of
> 'orif' and 'elsif' starting from the first posting and it never uses
> keyword 'orif' only.
>
> And your coding example is directly copied from your first post on
> this thread without any change.
>
> You wrote two assertion statements to show your assertion statement
> ability, but coding is wrong. You never wrote a assertion that
> includes 6 signals from E0 to E5, but your coding was based on it. It
> is a little error not affecting out discussions.
>
> 2. Jim asked:
> Can "ORIF" also construct the equivalent to the following?
> OutBusBProc : process(RESET, CLK)
> begin
> if(RESET =3D '1') then
> OutBus <=3D (others=3D>'0');
> elsif rising_edge(CLK) then
> OutBusB <=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 process ;
>
> Here is the answer:
>
> A : process(RESET, CLK)
> begin
> if(RESET =3D '1') then
> OutBus <=3D (others=3D>'0');
> elsif rising_edge(CLK) then
> if(E0 =3D '1') then
> OutBus <=3D Data0;
> orif(E1 =3D '1') then
> OutBus <=3D Data1;
> orif(E0 =3D '1') then
> OutBus <=3D Data2;
> orif(E0 =3D '1') then
> OutBus <=3D Data3;
> orif(E0 =3D '1') then
> OutBus <=3D Data4;
> orif(E0 =3D '1') then
> OutBus <=3D Data5;
> else
> OutBus <=3D Zero_64;
> end if;
> end if;
> end process;
>
> "ORIF' can not only do the above as an beginner would like to do, but
> also do the following equations you showed before more efficiently:
>
> -- assert zero_one_hot (E0, E1, E2) ; -- Jim wrote
> -- assert zero_one_hot (E3, E4, E5) ;
> assert zero_one_hot (E0, E1, E2, E3, E4, E5) ; -- Weng adds this line
> to make code correct
>
> -- It is Jim's coding
> 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;
>
> I don't know which VHDL version permits the operation: (E0 and Data0),
> even though It is not a problem here
>
> -- It is my coding
> A : process(RESET, CLK)
> begin
> if(RESET =3D '1') then
> OutBus <=3D (others=3D>'0');
> elsif rising_edge(CLK) then
> if(E0 =3D '1') then
> OutBus <=3D Data0;
> orif(E1 =3D '1') then
> OutBus <=3D Data1;
> orif(E2 =3D '1') then
> OutBus <=3D Data2;
> orif(E3 =3D '1') then
> OutBus <=3D Data3;
> orif(E4 =3D '1') then
> OutBus <=3D Data4;
> orif(E5 =3D '1') then
> OutBus <=3D Data5;
> else
> OutBus <=3D OutBus;
> end if;
> end if;
> end process;
>
> The above equation would be implemented in Xilinx chip with carry
> chain with initial input data to the carry chain being OutBus. The
> following enable equation would be eliminated from Jim's coding:
> (E0 or E1 or E2 or E3 or E4 or E5) =3D '1'
>
> It is not a LUT or two saving as some suggesed. For a up to 400MHz
> project, every extra logic would kill a design. Because it takes more
> route resources. When route resources exhausted, the running frequency
> would drop dramatically and would kill a otherwise successfu design.
> LUT is less than a cent in a FPGA.
>
> The above two example show that with mixed 'elsif' and 'orif' language
> branch statement structure, HDL will provide more powerful and concise
> way to deal with mutually...
>
> read more =BB
Colin,
My comment regarding indentation, though poorly stated on my part, was
intended to support the traditional use of indentation, which is to
visually indicate subordinate execution/analysis of statements. Since
orif is not executed subordinately to elsif any more than additional
elsif's are, it should not be indented beyond elsif.
In my informal proposal to Jim, I suggested that zero_one_hot() (or
some standard function with that purpose) be defined in a VHDL-
standard package as a VHDL function (i.e. in addition to, or
independent of, a similar PSL function) so that it could be used with
the VHDL ASSERT statement. Thus, if it were defined in a standard
package, then the function name could be prefixed with the package
name to make it unique from any other identifier.
Andy
Article: 123598Hello, I am working with xilinx (Spartan 2E). The DSP is off chip. I hope I found the problem today. You are right. It was a timing issue. I have an Input to the state machine that doesn't met the timing requirements. It is a ready signal that is generated from a device. After the read strobe the device asserts a ready signal. I doublechecked the timing of this pin again and found out that it is difficult to met timing from the clock cycle (where read strobe goes low) to the max delay of the activated ready signal within a clock cycle. I thought the ready signal is stable long befor the next rising clock edge occurs (bit it isn'nt). Now I do synchronisation and put some sync states in the state machine to get a synchronous ready signal. I let you know about the result. Thanks a lot for your help.Article: 123599
Let me ask other question. FPGA device consists of Huge SRAM cells (around 10 Mbits, xc2vp30-ff896) + memory controller + hard cores (such as PPC, multiplier) If we neglect hard cores, I guess that more than 95% of FPGA device is just array of SRAM cells. Does someone aware of these data? Thank you again.
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