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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 123575

Article: 123575
Subject: Re: PCB Impedance Control
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 30 Aug 2007 15:36:04 +0100
Links: << >>  << T >>  << A >>
"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
Subject: Re: New keyword 'orif' and its implications
From: Jim Lewis <jim@synthworks.com>
Date: Thu, 30 Aug 2007 07:46:04 -0700
Links: << >>  << T >>  << A >>
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: 123577
Subject: Re: New keyword 'orif' and its implications
From: Jim Lewis <jim@synthworks.com>
Date: Thu, 30 Aug 2007 08:08:26 -0700
Links: << >>  << T >>  << A >>
Colin 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,
Jim

Article: 123578
Subject: Re: Output signals not synchronized
From: Gabor <gabor@alacron.com>
Date: Thu, 30 Aug 2007 08:12:50 -0700
Links: << >>  << T >>  << A >>
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
Subject: Reconfiguration of a XUP Board
From: Sebastian Goller <sego@hrz.tu-chemnitz.de>
Date: Thu, 30 Aug 2007 08:17:13 -0700
Links: << >>  << T >>  << A >>
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 Goller


Article: 123580
Subject: Re: Spartan 3E starter kit (Rev.D) modification : 3E500 -> 3E1200
From: dormanpeter1@gmail.com
Date: Thu, 30 Aug 2007 15:28:20 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: Spartan3E and DDR termination
From: Gabor <gabor@alacron.com>
Date: Thu, 30 Aug 2007 08:41:45 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Reconfiguration of a XUP Board
From: Gabor <gabor@alacron.com>
Date: Thu, 30 Aug 2007 08:50:46 -0700
Links: << >>  << T >>  << A >>
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,
Gabor


Article: 123583
Subject: Re: modelsim
From: fpgabuilder <fpgabuilder-groups@yahoo.com>
Date: Thu, 30 Aug 2007 16:10:32 -0000
Links: << >>  << T >>  << A >>
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


Article: 123584
Subject: Re: Xilinx / ISE multi-cycle path constraint pitfall
From: eli.billauer@gmail.com
Date: Thu, 30 Aug 2007 16:10:54 -0000
Links: << >>  << T >>  << A >>
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: 123585
Subject: Die size, pitch size?
From: Pasacco <pasacco@gmail.com>
Date: Thu, 30 Aug 2007 09:14:31 -0700
Links: << >>  << T >>  << A >>
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
Die size = 31 mm x 31 mm

Could someone explain this?
Am I correct?


Article: 123586
Subject: Re: Registered output for Altera on-chip memory
From: fpgabuilder <fpgabuilder-groups@yahoo.com>
Date: Thu, 30 Aug 2007 16:15:11 -0000
Links: << >>  << T >>  << A >>
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.

-sanjay


Article: 123587
Subject: Re: modelsim
From: fazulu deen <fazulu.vlsi@gmail.com>
Date: Thu, 30 Aug 2007 09:43:48 -0700
Links: << >>  << T >>  << A >>
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,
fazal


Article: 123588
Subject: Re: Xilinx / ISE multi-cycle path constraint pitfall
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 30 Aug 2007 17:53:22 +0100
Links: << >>  << T >>  << A >>
<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
Subject: Re: Xilinx / ISE multi-cycle path constraint pitfall
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 30 Aug 2007 18:04:07 +0100
Links: << >>  << T >>  << A >>
"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
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Thu, 30 Aug 2007 10:08:05 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Die size, pitch size?
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Thu, 30 Aug 2007 17:24:02 +0000 (UTC)
Links: << >>  << T >>  << A >>
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: 123592
Subject: Re: Output signals not synchronized
From: EEngineer <maricic@gmail.com>
Date: Thu, 30 Aug 2007 17:35:16 -0000
Links: << >>  << T >>  << A >>
On 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
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Thu, 30 Aug 2007 10:43:30 -0700
Links: << >>  << T >>  << A >>
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: 123594
Subject: Re: New keyword 'orif' and its implications
From: Jim Lewis <jim@synthworks.com>
Date: Thu, 30 Aug 2007 11:11:52 -0700
Links: << >>  << T >>  << A >>
Weng,
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,
Jim



Article: 123595
Subject: An FPGA startup is seeking testcase from potential customers
From: siliconbluetechnology@yahoo.com
Date: Thu, 30 Aug 2007 11:21:56 -0700
Links: << >>  << T >>  << A >>
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.com


Article: 123596
Subject: Re: New keyword 'orif' and its implications
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 30 Aug 2007 11:25:21 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: New keyword 'orif' and its implications
From: Andy <jonesandy@comcast.net>
Date: Thu, 30 Aug 2007 11:42:21 -0700
Links: << >>  << T >>  << A >>
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: 123598
Subject: Re: Strange behaviour of a design
From: markus.jank@gmx.de
Date: Thu, 30 Aug 2007 11:44:56 -0700
Links: << >>  << T >>  << A >>
Hello,

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
Subject: Re: Die size, pitch size?
From: Pasacco <pasacco@gmail.com>
Date: Thu, 30 Aug 2007 11:57:25 -0700
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search