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 153375

Article: 153375
Subject: Re: Dangling all pins, DIA0 through DIA31
From: aleksa <aleksazr@gmail.com>
Date: Fri, 10 Feb 2012 12:07:36 -0800 (PST)
Links: << >>  << T >>  << A >>
> No. Open pins should generate a warning. Just tie them to '0'.

OK.

But ISE should do that automatically, because there are
other input pins in the BRAM that I'm not using,
and ISE is not complaining about those pins.

Anyone knows how do I do that in specifically this project?

Article: 153376
Subject: Re: Difference between Xilinx isim and modelsim
From: Alan Fitch <apf@invalid.invalid>
Date: Sat, 11 Feb 2012 01:10:23 +0000
Links: << >>  << T >>  << A >>
On 07/02/12 15:50, Andy wrote:
> On Feb 2, 6:48 pm, Alan Fitch <a...@invalid.invalid> wrote:
>> On 03/02/12 00:16, Alan Fitch wrote:
>>
<snip>
> 
> I will have to go back and read the definition of LSP. I agree with
> your assessment that these are locally static names; the question is
> "what is the relation between a locally static name for an element or
> slice of an aggregate, and the longest static prefix for  than element
> or slice?" It was my understanding that if there is a named aggregate
> that contains the object referred to by the locally static name, then
> the aggregate is still the LSP, not the locally static name. It likely
> has to do with whether events are tracked separately on inidividual
> elements of a named aggregate signal, or whether they are only tracked
> at the aggregate level.
>

The statement I noticed was

"The longest static prefix of a signal name is the name itself, if the
name is a static signal name;"

> And I may be entirely wrong...
>

and so may I :-)

> Thanks for the discussion,
>

That's OK, it's sort of fun! I wonder what the original poster thinks...

Alan



-- 
Alan Fitch

Article: 153377
Subject: Re: Dangling all pins, DIA0 through DIA31
From: aleksa <aleksazr@gmail.com>
Date: Sat, 11 Feb 2012 04:24:17 -0800 (PST)
Links: << >>  << T >>  << A >>
I've created a similar project, just replacing ROM with RAM.
http://www.mediafire.com/?nlpnn3xs5z940ox

1. synthesize, implement
2. comment and uncomment lines 46, 47
3. synthesize, re-implement

it seems it has something to do with the WEA signal

Article: 153378
Subject: Re: Design Notation VHDL or Verilog?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Sun, 12 Feb 2012 17:24:26 +0100
Links: << >>  << T >>  << A >>
nico@puntnl.niks (Nico Coesel) writes:

> Petter Gustad <newsmailcomp6@gustad.com> wrote:
>
>>nico@puntnl.niks (Nico Coesel) writes:
>>
>>>>There are several nice features like interfaces (which are
>>>>bi-directional unlike record bundles in VHDL). There's also enum's,
>>>
>>> Record bundles can be bi-directional in VHDL!
>>
>>That's great news as I've always used one record type as input and
>>another one as output.
>
> Just declare the port as inout. Its simple as that.

That might cause some problems. I've seen some tool which did not like
inouts other than at the top level (can't remember which, it might
have been some LSI or IBM tool). This is many years ago and might not
be the case in more recent versions. Also you'll miss the compile
static check of only one driving the signal.

//Petter


-- 
.sig removed by request. 

Article: 153379
Subject: Re: Design Notation VHDL or Verilog?
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 12 Feb 2012 21:35:17 GMT
Links: << >>  << T >>  << A >>
Petter Gustad <newsmailcomp6@gustad.com> wrote:

>nico@puntnl.niks (Nico Coesel) writes:
>
>> Petter Gustad <newsmailcomp6@gustad.com> wrote:
>>
>>>nico@puntnl.niks (Nico Coesel) writes:
>>>
>>>>>There are several nice features like interfaces (which are
>>>>>bi-directional unlike record bundles in VHDL). There's also enum's,
>>>>
>>>> Record bundles can be bi-directional in VHDL!
>>>
>>>That's great news as I've always used one record type as input and
>>>another one as output.
>>
>> Just declare the port as inout. Its simple as that.
>
>be the case in more recent versions. Also you'll miss the compile
>static check of only one driving the signal.

The synthesizer will most likely complain about that.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 153380
Subject: Re: Design Notation VHDL or Verilog?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Sun, 12 Feb 2012 23:21:47 +0100
Links: << >>  << T >>  << A >>
nico@puntnl.niks (Nico Coesel) writes:

>>be the case in more recent versions. Also you'll miss the compile
>>static check of only one driving the signal.
>
> The synthesizer will most likely complain about that.

I was thinking about simulator compile checks. Which typically can be
checked quickly, e.g. can be done from the editor and prior to
revision control commits etc. Synthesis usually takes longer.

//Petter

-- 
.sig removed by request. 

Article: 153381
Subject: Re: Life after XDL
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Mon, 13 Feb 2012 10:11:39 +0000
Links: << >>  << T >>  << A >>
I too have tools which make use of XDL (one of which some of you may
have used - FPGA Optim); so after Neil's heads-up, I contacted my local
Xilinx guy and got this response (which I must make clear is not an
"official factory response"):

"Because of the database change in Rodin, XDL is not part of this new
tool. This is being debated by the technical teams at Xilinx. One
solution offered so far is to use TCL instead as this will enable full
access to the database to change the FPGA design / routing similar to
XDL."

So, there is an awareness of the problem, and hopefully a (albeit
different) solution, although it sounds like they are not committed to
providing it at the moment.

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 153382
Subject: MPMC simulation
From: "Saylee" <saylee.24@n_o_s_p_a_m.gmail.com>
Date: Tue, 14 Feb 2012 07:55:23 -0600
Links: << >>  << T >>  << A >>
Hi,

     I am simulating MPMC with Isim version 12.4. I have written a test
bench to give inputs to microblaze instance. Here i am facing problem of
MPMC simulation. The MPMC is not generating NPI output signals like
MCB_DDR2_PIM1_InitDone_pin, MCB_DDR2_PIM1_WrFIFO_Empty_pin etc as required.
Please help me in this problem. 
  
Thank you...

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153383
Subject: LUT6 FPGAs and Carry Logic
From: Jan Bruns <jansaccount@arcor.de>
Date: 14 Feb 2012 23:13:38 GMT
Links: << >>  << T >>  << A >>

Hallo.

Some questions about Xilinx LUT6 FPGAs (my WebPack Toolchain is
a little outdated, and the newer LUT6-FPGAs don't seem to show
up correctly in fpga_editor).

* Is there really no carry-bypass option in LUT6-paths like the 
  CYMUX(any,cin,1) living in LUT4 paths, apart from
  constraining the LUTs?

* SLICEMs and SLICELs always have a carry chain, while SLICEXs 
  neither have a RAM nor a carry option?

* Within a CLB, SLICEMs are paired with SCLICEX (if there are 
  SLICEXs in the device)? Sounds strange to me: If a LUT is
  configured to be dynamic, it is probably very likely that
  additional Carry logic isn't used, compared to static LUTs
  (with LUT4s, one rare reason to this is using the carry chain
  to implement a post-invert option for the RAM...). Have you ever 
  seen a dynamic LUT6 really gain something in also using carry?

* What about production? Does it look like Xilinx might stop selling
  and developing new LUT4-FPGAs in the near future? I personally
  don't have enough overview about these two FPGA classes, so I
  can't see the detailed pros and cons. 

Gruss

Jan Bruns

-- 
Ein paar Fotos: http://abnuto.de/gal/

Article: 153384
Subject: Re: Life after XDL
From: Jan Bruns <jansaccount@arcor.de>
Date: 15 Feb 2012 01:39:54 GMT
Links: << >>  << T >>  << A >>

Neil Steiner:

> If you know and love XDL or XDLRC, and if you believe that the research
> community's access to these tools provides a benefit to Xilinx, this is
> your opportunity to speak up.  The xdl tool will no longer be available
> as of ISE 14, and unofficial word is that Xilinx does not intend to
> provide equivalent capability.  We don't believe they're deliberately
> trying to withhold that capability:  We simply think they see it as a
> distraction that provides no benefit for them.
> 
> /For those who may be unfamiliar with these tools, XDL is a format that
> can be converted to or from mapped NCD, allowing the user to modify any
> part of their circuit or its placement or routing, or to perform
> arbitrary placement and routing of their own.  XDLRC provides all of the
> logic and interconnect data for real Xilinx devices, and enables
> research into CAD algorithms for real devices. /
> A colleague from BYU (representing RapidSmith) and I (representing Torc)
> are scheduled to meet with the Xilinx software folks in two weeks to
> discuss this matter, and to appeal for continued functionality
> equivalent to XDL and XDLRC.  We have no wish to barrage or pressure
> them in any way.  The data is theirs to do with as they think best.  But
> to the extent that our community's access to XDL benefits them, we would
> like to present that case to them.
> 
> I am collecting and framing our arguments, and am open to any
> contributions from the comp.arch.fpga community.  Any of the following
> would be helpful to our cause, in rough decreasing order of importance.
> And I relax the strict meaning of XDL here to include capabilities and
> low-level device knowledge enabled by XDL:

I'm only a hobbyist, so I actually don't have any evidence about 
financial matters. 

But I've noticed the existance of the XDL tool, and used it a few times,
but just for informational purposes. Using fpga_editor, I've noticed that 
the automatic router is sometimes pretty difficut to guide. It sometimes 
gives up searching for completely obvious, essential solutions. 
Timing costraints can help in finding out if an essential solution was
found, but don't give the router all the already known information
about modules. For example,. things like "just priotize these signals and 
everything will easily work out as the timing constraints told" just imply
theoretical satisfyability, but no real world solution, if there's no way
to tell the tool.

"No way to tell the tool" + "stupid hobbyist realized it" prooves that
there should be third party tools "to tell the tool" in some of the
commericially more relevant workflows.

Gruss

Jan Bruns

-- 
Ein paar Fotos: http://abnuto.de/gal/

Article: 153385
Subject: Anybody here got a Xilinx ML605?
From: pfraser <pete_fraser@comcast.net>
Date: Tue, 14 Feb 2012 21:09:06 -0800
Links: << >>  << T >>  << A >>
I'm having trouble running the application described in
XAPP740 (Designing high-performance video systems with the
AXI interconnect).

I have tried running the pre-built images, and building my own.
In both cases it seems to hang during the initialization of
the DVI transmitter.

If I just run the software it sometimes sends out a few bytes
to the DVI transmitter before it hangs; sometimes it hangs
endlessly pulsing SCL before it sends out any valid data.

If I debug the software it invariably hangs waiting for the busy
bit in the status register (during the first invocation of
XIic_DynSend. The core is the AXI IIC Bus Interface (v1.01a).

One thing I noticed is that, while SCL always gets down to
0V, SDA sometimes gets to 0V, and sometimes only to 0.6V.
I have no idea why this might be, as I see this when the
V6 should be driving.

I have verified that the demo images that the board is shipped
with seem to work correctly. On reset I get the Xilinx splash
screen, and a reasonable sequence of IIC writes and reads to
the DVI transmitter. I still some weak lows though.

Anybody else working with XAPP740? Any idea what might be wrong?
I asked in the Xilinx forums, but received a thundering silence.

Thanks

Pete

Article: 153386
Subject: Re: LUT6 FPGAs and Carry Logic
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Wed, 15 Feb 2012 09:14:32 +0000
Links: << >>  << T >>  << A >>
Jan Bruns <jansaccount@arcor.de> writes:

> Hallo.
>
> Some questions about Xilinx LUT6 FPGAs (my WebPack Toolchain is
> a little outdated, and the newer LUT6-FPGAs don't seem to show
> up correctly in fpga_editor).
>

The datasheets and usermanuals show everything you would need I think
though...  see UG384 for example.  Pages 9-11 show the various slices in
some detail.

> * Is there really no carry-bypass option in LUT6-paths like the 
>   CYMUX(any,cin,1) living in LUT4 paths, apart from
>   constraining the LUTs?
>

I'm not sure what you mean by constraining the LUTs.  There are various
muxes shown in Fig 3,4,5 - can you achieve what you want with them?

> * SLICEMs and SLICELs always have a carry chain, while SLICEXs 
>   neither have a RAM nor a carry option?
>

Correct

> * Within a CLB, SLICEMs are paired with SCLICEX (if there are 
>   SLICEXs in the device)? Sounds strange to me: If a LUT is
>   configured to be dynamic, it is probably very likely that
>   additional Carry logic isn't used, compared to static LUTs
>   (with LUT4s, one rare reason to this is using the carry chain
>   to implement a post-invert option for the RAM...). Have you ever 
>   seen a dynamic LUT6 really gain something in also using carry?
>

It seems to me that there are "big slices", "medium slices" and "smal
slices" - the silicon area taken up by the carry chain may well be
"free" compared to the rest of the big/medium slices.

Additionally, SLICEMs can be used for dynamic filter-coefficient
storage, the arithmetic logic is also useful then.

Xilinx will have pushed an awful lot of existing and potential designs
through this architecture and decided its a win overall.  Whether it's a
win for your particular designs and style is immaterial to them (unless
you are an *enormous* customer!)

> * What about production? Does it look like Xilinx might stop selling
>   and developing new LUT4-FPGAs in the near future? 

Selling... I doubt they'll stop selling Spartan 3 (for example) for a
very long time yet - Xilinx have a long history of keeping old families
going for many many years after it was sensible to design them into new
systems.

Developing... Spartan 3(and E,A,ADSP) was the last LUT4 generation, so
yes, I think it's stopped!  

My understanding of the the Series 7 goal is to make as much of the
user-visible logic as possible identical across the three ranges (Artix,
Kintex and Virtex).  There are differences in power/speed tradeoffs and
the mix of memory, DSP, gigabit IO, logic etc. But the fundamental
blocks are the same throughout.  Unlike in the V5/S3 era when the LUTS,
DSPs, BRAMs, IOs were all different between the two families!

> I personally don't have enough overview about these two FPGA classes,
> so I can't see the detailed pros and cons.

I'm not sure there's much to care about pros and cons.  LUT6 is here,
unless you want to design with relatively old chips.

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 153387
Subject: Re: Anybody here got a Xilinx ML605?
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Wed, 15 Feb 2012 10:16:15 +0100
Links: << >>  << T >>  << A >>
"pfraser" <pete_fraser@comcast.net> wrote in message 
news:jhfeln$79b$1@dont-email.me...
> I'm having trouble running the application described in
> XAPP740 (Designing high-performance video systems with the
> AXI interconnect).

I dont know much about this project, but something about i2c captured my 
attention.

> One thing I noticed is that, while SCL always gets down to
> 0V, SDA sometimes gets to 0V, and sometimes only to 0.6V.
> I have no idea why this might be, as I see this when the
> V6 should be driving.

There are several possible reasons why SDA don't go all the way down. Here 
are two common ones.
1.High drive (somthing is driving the SDA high instead of using "releasing" 
it with a open drain drive). Only bad hw implementations does this.
2.Long wires. If something at the end of a long wire pulls down, there will 
be a voltage drop at the receiver. This happens typically when communicating 
with a DVI monitor over the DDC bus.



Article: 153388
Subject: Re: Anybody here got a Xilinx ML605?
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Wed, 15 Feb 2012 10:24:23 +0100
Links: << >>  << T >>  << A >>
Oh, and I can add:
A pulsing SCL can indicate that the master is trying to get SDA high so it 
can make a start/stop. If any slave or design error is holding SDA low, 
there can be no start/stop condition. This is why all i2c initiation should 
start with a up to 9 clock loop looking for SDA=high before sending a stop. 
Some implementation may be lazy and loop forever instead of giving up with 
an error msg.
No devices will hold SDA for more than 8 clks wich makes this a guaranteed 
start condition.
Also notice that if you hotplug i2c devices (like monitors with DDC bus), 
there is no guaranee that slaves are in stopped state when you attach them 
unless you do this init cycle. If a slave happened to be in the middle of 
something, got disconnected but kept its power, then reconnected later in 
the middle of something else, you will get conflict. This can only be solved 
by proper init.



Article: 153389
Subject: JAM Stapl player on 64 bit platform?
From: wzab <wzab01@gmail.com>
Date: Wed, 15 Feb 2012 01:35:15 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

A few years ago I've prepared the customized version of JAM STAPL
Player, well suited for operation in VME based environment with
SCANSTA111 bridge (open sourced and published e.g. at
http://groups.google.com/group/alt.sources/browse_thread/thread/8761df1865c088f4/ce9a5358866aa4fa
).

It worked correctly for a few years, but now we are forced to switch
to 64-bit platform.
Unfortunately the original JAM STAPL player code seems to be
inherently 32-bit.

I'd like to know if anybody has succesfully ported the sources of JAM
STAPL Player to 64-bit platform?
Is there any other open source solution which could be easily adapted
to efficiently drive the JTAG chain via VME interface?
--
TIA,
Wojtek Zabolotny



Article: 153390
Subject: Re: JAM Stapl player on 64 bit platform?
From: wzab <wzab01@gmail.com>
Date: Wed, 15 Feb 2012 01:50:21 -0800 (PST)
Links: << >>  << T >>  << A >>
I have found an SVF based solution:

http://www.clifford.at/libxsvf/

but again there is no info if it is 64-bit safe...
--
Regards,
WZab


Article: 153391
Subject: Re: Anybody here got a Xilinx ML605?
From: pfraser <pete_fraser@comcast.net>
Date: Wed, 15 Feb 2012 04:24:54 -0800
Links: << >>  << T >>  << A >>
Morten Leikvoll wrote:
> "pfraser"<pete_fraser@comcast.net>  wrote in message
>
>> One thing I noticed is that, while SCL always gets down to
>> 0V, SDA sometimes gets to 0V, and sometimes only to 0.6V.
>
> There are several possible reasons why SDA don't go all the way down. Here
> are two common ones.
> 1.High drive (somthing is driving the SDA high instead of using "releasing"
> it with a open drain drive). Only bad hw implementations does this.

I haven't yet looked at the HDL. I'll do that next.

> 2.Long wires. If something at the end of a long wire pulls down, there will
> be a voltage drop at the receiver. This happens typically when communicating
> with a DVI monitor over the DDC bus.

That was my first thought, but I still get the bad low even
with the monitor disconnected.

Thanks

Pete

Article: 153392
Subject: Re: Anybody here got a Xilinx ML605?
From: pfraser <pete_fraser@comcast.net>
Date: Wed, 15 Feb 2012 04:31:48 -0800
Links: << >>  << T >>  << A >>
Morten Leikvoll wrote:
> Oh, and I can add:
> A pulsing SCL can indicate that the master is trying to get SDA high so it
> can make a start/stop. If any slave or design error is holding SDA low,
> there can be no start/stop condition. This is why all i2c initiation should
> start with a up to 9 clock loop looking for SDA=high before sending a stop.
> Some implementation may be lazy and loop forever instead of giving up with
> an error msg.

A good clue. I had noticed that, when the unit failed with
the pulsing SCL, it failed before my breakpoint (i.e., earlier
than I expected) and it failed with SDA low-ish. I was triggering
my scope on SCL going low, so I didn't see the SDA go low.
Today I'll trigger on SDA going low, and see when in the SW that
happens. This is all supposed to be tested code, so I was
assuming it is something wrong with my board, but perhaps I'm
being too trusting.

Thanks

Pete

Article: 153393
Subject: problem with Global Clock pin and normal IO pin as Clock input
From: "nba83" <nba_baheri@n_o_s_p_a_m.yahoo.com>
Date: Wed, 15 Feb 2012 07:58:44 -0600
Links: << >>  << T >>  << A >>
hi
i am trying to detect falling edge of a 200ns pulse(WriteStrobe)
synchronously with this code. GlobalClk is 100MHz(10ns) oscillator clk
attached to global clk pin of Xilinx Spartan 3 XC3s400-5I. the problem i am
facing is that about 1000 falling edges 100 of them are missed. i used
IBUFG at the input clk but the output is the same. but if I connect the
oscillator to a normal io pin with the constraint CLOCK_DEDICATED_ROUTE =
FALSE; i can detect all the falling edges without error. i don't know
what's the problem. any help would be appreciated :)
	 always @(posedge GlobalClk)
	 begin
		pre_WriteStrobe <= WriteStrobe;
		if(  pre_WriteStrobe & ~WriteStrobe)
		begin			
			StartWritingMemory <=1;			
			WriteNibble <=0;
			Write_Address <= 4095;		
		end 
        end

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153394
Subject: Re: problem with Global Clock pin and normal IO pin as Clock input
From: Gabor <gabor@szakacs.invalid>
Date: Wed, 15 Feb 2012 10:07:21 -0500
Links: << >>  << T >>  << A >>
nba83 wrote:
> hi
> i am trying to detect falling edge of a 200ns pulse(WriteStrobe)
> synchronously with this code. GlobalClk is 100MHz(10ns) oscillator clk
> attached to global clk pin of Xilinx Spartan 3 XC3s400-5I. the problem i am
> facing is that about 1000 falling edges 100 of them are missed. i used
> IBUFG at the input clk but the output is the same. but if I connect the
> oscillator to a normal io pin with the constraint CLOCK_DEDICATED_ROUTE =
> FALSE; i can detect all the falling edges without error. i don't know
> what's the problem. any help would be appreciated :)
> 	 always @(posedge GlobalClk)
> 	 begin
> 		pre_WriteStrobe <= WriteStrobe;
> 		if(  pre_WriteStrobe & ~WriteStrobe)
> 		begin			
> 			StartWritingMemory <=1;			
> 			WriteNibble <=0;
> 			Write_Address <= 4095;		
> 		end 
>         end
> 
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

You can't use the asynchronous input in your "if" clause.  To
properly sense the falling edge of an asynchronous input you
need two flops and then compare the outputs of those flops.
If instead you compare the output of the first flop to the
input signal (yes I know this would have less latency) you
have the possibility of a vanishingly small time when the
two signals are different.  Then you don't meet the setup
time to the registers inside your if statement.

Try this:

reg [1:0] pre_WriteStrobe;

  	 always @(posedge GlobalClk)
  	 begin
  		pre_WriteStrobe <= {pre_WriteStrobe[0],WriteStrobe};
  		if(  pre_WriteStrobe[1] & ~pre_WriteStrobe[0])
  		begin			
  			StartWritingMemory <=1;			
  			WriteNibble <=0;
  			Write_Address <= 4095;		
  		end
          end


-- Gabor

Article: 153395
Subject: Major New Release of Public-Domain FPGA Architecture and CAD Research
From: Jonathan Rose <jonathanscottrose@gmail.com>
Date: Wed, 15 Feb 2012 10:15:40 -0800 (PST)
Links: << >>  << T >>  << A >>
For those interested in FPGA CAD and architecture research, we are
pleased to announce the full release of the Verilog-to-Routing (VTR)
project version 1.0.  VTR consists of a suite of CAD tools, circuit
benchmarks, FPGA architectures, and experiment scripts to aid those in
the community to explore new FPGAs as well as algorithms to map to
future FPGAs.  This effort is an international collaboration of
researchers, and consists of three software tools:  ODIN II for
Verilog Elaboration, ABC (from Berkeley) for Logic Synthesis, and VPR
for packing, placement, routing and timing analysis.

You can find detailed information on the new release here:

http://code.google.com/p/vtr-verilog-to-routing/

This new full release has many new features and has been extensively
tested.  It is also worth noting that all three tools are Open Source.
In particular, that is now true of VPR, which is new.

This new version of VTR is now fully timing driven in the packing,
place and routing phase of VPR.  The previous, alpha release (which
was not timing-driven), enabled the description of far more complex
logic blocks, including the popular Fracturable blocks (such as LUTs
than can operate as one big LUT or two smaller LUTs) in modern
commercial FPGAs.   There is also explicit support for hard  memories
and multipliers from the Verilog level on down.

This release contains architecture files and benchmark circuits that
make use of Fracturable LUTs, memories and multipliers.  The set of
benchmark circuits in this release are from real applications many of
which contain multipliers and memories.  The largest of these circuits
is almost 100,000 6-LUTs.  In additional to these benchmarks, we also
included the old MCNC circuits as well as a set of circuits that use
embedded floating-point cores.

We provide CAD/Architecture scripts that show how to run various
experiments.  As good science needs to be repeatable, we have included
our results so that users of VTR can easily replicate the same results
that we obtained.

We made a strong effort to make a more user friendly build experience.
Building VTR should be as simple as entering make in the main
directory.  Testing the flow should be as easy as running a script
that reports what successfully built and what did not.

If you are interested in downloading VTR or getting more information
about it, please visit our website here:

http://code.google.com/p/vtr-verilog-to-routing/

The VTR development team:

University of Toronto: Jason Luu, Jason Anderson, Vaughn Betz, Opal
Densmore, Cong Wang, Peter Milankov, Jonathan Rose
University of New Brunswick: Kenneth B. Kent, Ash Furrow, Paddy
O'Brien, Joey Libby, Shubham Jain, Konstantin Nasartschuk, Andrew
Somerville

University of British Columbia: Jeff Goeders, Eddie Hung

U. Penn: Rafi Rubin

U Miami, Ohio: Peter Jamieson

City University of Hong Kong: Chi Wai Yu

(Many thanks to Robert Brayton and Alan Mischenko at U.C. Berkeley for
the use of the ABC Logic Synthesis tool).

Article: 153396
Subject: Re: LUT6 FPGAs and Carry Logic
From: Jan Bruns <jansaccount@arcor.de>
Date: 15 Feb 2012 21:21:42 GMT
Links: << >>  << T >>  << A >>

Martin Thompson:
> Jan Bruns:

>> Some questions about Xilinx LUT6 FPGAs (my WebPack Toolchain is a
>> little outdated, and the newer LUT6-FPGAs don't seem to show up
>> correctly in fpga_editor).

> The datasheets and usermanuals show everything you would need I think
> though...  see UG384 for example.  Pages 9-11 show the various slices in
> some detail.

Thanks. I've tested the wrong datasheets then.
 
>> * Is there really no carry-bypass option in LUT6-paths like the
>>   CYMUX(any,cin,1) living in LUT4 paths, apart from constraining the
>>   LUTs?

> I'm not sure what you mean by constraining the LUTs.  There are various
> muxes shown in Fig 3,4,5 - can you achieve what you want with them?

The select-Input of the main Carry-Select Muxes is directly connected
to the LUT-output, without an option to put another signal on it.
If you make use of the Carry Logic, the function you put on the LUT
will always become part of the Carry calculation.

Xilinx LUT4 FPGAs had an option to make the main CarrySelect Mux always
fprward the cin to cout, no matter of the LUT said. This was pretty 
useful, because it was possible to make relatively huge logic feed
the Carry Chain, without ever crossing CLB boundaries.

For example, within a SLICE, it was possible to have one LUT act as 
16-bit RAM, and have it added (or whatever) to some external value on 
the other LUT. The RAM-LUTs output was not expected to directly
connect to the Carry Logic, but had relatively fast routes to
the arithmetic then.

However, I'd expect many reasons to use "partial populated"
carry chains to be gone with LUT6.
 
>> * Within a CLB, SLICEMs are paired with SCLICEX (if there are
>>   SLICEXs in the device)? Sounds strange to me: If a LUT is configured
>>   to be dynamic, it is probably very likely that additional Carry logic
>>   isn't used, compared to static LUTs (with LUT4s, one rare reason to
>>   this is using the carry chain to implement a post-invert option for
>>   the RAM...). Have you ever seen a dynamic LUT6 really gain something
>>   in also using carry?

> It seems to me that there are "big slices", "medium slices" and "smal
> slices" - the silicon area taken up by the carry chain may well be
> "free" compared to the rest of the big/medium slices.

Hmn, sounds like that's only one theory of yours.
 
> Additionally, SLICEMs can be used for dynamic filter-coefficient
> storage, the arithmetic logic is also useful then.

Hm, what about details, then?
A dynloadable LUT1 calculating "external signal xor stored bit"?

> Xilinx will have pushed an awful lot of existing and potential designs
> through this architecture and decided its a win overall.
> Whether it's a win for your particular designs and style is immaterial 
> to them (unless you are an *enormous* customer!)

Compared to what? LUT4 vs. LUT6, given the same silicon process?
What would you expect the term "win" to represent, then?

I don't believe there's no market for LUT4 FPGAs using current 
silicon process.

>> * What about production? Does it look like Xilinx might stop selling
>>   and developing new LUT4-FPGAs in the near future?

> Selling... I doubt they'll stop selling Spartan 3 (for example) for a
> very long time yet - Xilinx have a long history of keeping old families
> going for many many years after it was sensible to design them into new
> systems.
 
> Developing... Spartan 3(and E,A,ADSP) was the last LUT4 generation, so
> yes, I think it's stopped!

>> I personally don't have enough overview about these two FPGA classes,
>> so I can't see the detailed pros and cons.
 
> I'm not sure there's much to care about pros and cons.  LUT6 is here,
> unless you want to design with relatively old chips.

Argh. So all these valuable customers have to rework all parts of
their highly optimized, huge module database, just because Xilinx 
engineers thought it might be less work for them to ever put LUT6 in 
silicon?

Gruss

Jan Bruns

-- 
Ein paar Fotos: http://abnuto.de/gal/

Article: 153397
Subject: Re: LUT6 FPGAs and Carry Logic
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Thu, 16 Feb 2012 00:53:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 15, 10:21=A0pm, Jan Bruns <jansacco...@arcor.de> wrote:

> I don't believe there's no market for LUT4 FPGAs using current
> silicon process.

Market: Maybe.
Resonable facts to support such an architecture: No.

The problem here is that users tend to evaluate the capabilites of an
FPGA mainly
as logic, while really you pay mostly for routing. Logic is a very
small portion of the
silicon area. Of course the vendors don't publish the numbers, but
university research
suggests the area of LUT and LUT configuration is only a few percent
of total area.

Therefore when going from 4-LUT to 6-LUT you don't get a 4x area
increase (16 entries
to 64 entries) but more like a 60% increase (going from 4 inputs that
must be routed to
6 inputs that must be routed in a somewhat worse than linear routing
area).
This is offset by the fact that routing now gets a lot simpler.

Routing increases faster than linear with the number of wires.
Therefore with bigger
FPGAs the percentage of logic goes down. The optimum LUT size
therefore tends to go
up with technology improvements.

Research shows that the efficiency curve for FPGA technologies is
relatively flat around
the optimum. E.g. for a given technology there are multiple LUT sizes
that get you almost
the same area efficiency. Because performce tends to be better for the
larger LUTs and
because the software runtimes go down for larger LUTs (mapping is
polynomial time, routing
exponential) a typical design decision would be to chose the largest
LUT size within the
flat region of the curve, expecting that future implementations of the
architecture would
move the optimum spot in that direction.

This is exactly what FPGA vendors did:
In the early 90ies the sweet spot was consistenly show to be between 3-
LUTs and 4-LUTs so
most vendors chose 4-LUTs.

Newer research shows the flat region to be go from 4-LUTs to 6-LUTs.
While 4-LUTs probably
would be still a good choice, it is clear that there must be switch to
6-LUTs at some time, and
one might just as well do the switch now getting much better EDA
software run times.

Kolja Sulimma
cronologic.de










Article: 153398
Subject: Re: LUT6 FPGAs and Carry Logic
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 16 Feb 2012 11:36:03 +0000
Links: << >>  << T >>  << A >>
Jan Bruns <jansaccount@arcor.de> writes:

> Martin Thompson:
>> Jan Bruns:
>
>>> * Is there really no carry-bypass option in LUT6-paths like the
>>>   CYMUX(any,cin,1) living in LUT4 paths, apart from constraining the
>>>   LUTs?
>
>> I'm not sure what you mean by constraining the LUTs.  There are various
>> muxes shown in Fig 3,4,5 - can you achieve what you want with them?
>
> The select-Input of the main Carry-Select Muxes is directly connected
> to the LUT-output, without an option to put another signal on it.
> If you make use of the Carry Logic, the function you put on the LUT
> will always become part of the Carry calculation.
>
> Xilinx LUT4 FPGAs had an option to make the main CarrySelect Mux always
> fprward the cin to cout, no matter of the LUT said. This was pretty 
> useful, because it was possible to make relatively huge logic feed
> the Carry Chain, without ever crossing CLB boundaries.
>
> For example, within a SLICE, it was possible to have one LUT act as 
> 16-bit RAM, and have it added (or whatever) to some external value on 
> the other LUT. The RAM-LUTs output was not expected to directly
> connect to the Carry Logic, but had relatively fast routes to
> the arithmetic then.
>
> However, I'd expect many reasons to use "partial populated"
> carry chains to be gone with LUT6.
>  

Yes, I agree.  No doubt there will be *some* designs which don't work out
so well in the newer architectures.

>>> * Within a CLB, SLICEMs are paired with SCLICEX (if there are
>>>   SLICEXs in the device)? Sounds strange to me: If a LUT is configured
>>>   to be dynamic, it is probably very likely that additional Carry logic
>>>   isn't used, compared to static LUTs (with LUT4s, one rare reason to
>>>   this is using the carry chain to implement a post-invert option for
>>>   the RAM...). Have you ever seen a dynamic LUT6 really gain something
>>>   in also using carry?
>
>> It seems to me that there are "big slices", "medium slices" and "smal
>> slices" - the silicon area taken up by the carry chain may well be
>> "free" compared to the rest of the big/medium slices.
>
> Hmn, sounds like that's only one theory of yours.
>  

Well, yes, it is - you'll have to wait for someone from Xilinx for
anything better than that :)

>> Additionally, SLICEMs can be used for dynamic filter-coefficient
>> storage, the arithmetic logic is also useful then.
>
> Hm, what about details, then?

Well, I only offer it as a possibility (haven't done an actual
comparison), but distributed arithmetic FIR filters were what I was
thinking of.

>> Xilinx will have pushed an awful lot of existing and potential designs
>> through this architecture and decided its a win overall.
>> Whether it's a win for your particular designs and style is immaterial 
>> to them (unless you are an *enormous* customer!)
>
> Compared to what? LUT4 vs. LUT6, given the same silicon process?
> What would you expect the term "win" to represent, then?
>

Don't ask me - I'm not making the decisions.  Ultimately, Xilinx
presumably decided it was a "win" in business terms: "We'll make the
most money doing it this way."

> I don't believe there's no market for LUT4 FPGAs using current 
> silicon process.

No-one is saying there is not a market.  Just that it's not big enough
for Xilinx to be targetting it.

>
>>> * What about production? Does it look like Xilinx might stop selling
>>>   and developing new LUT4-FPGAs in the near future?
>
>> Selling... I doubt they'll stop selling Spartan 3 (for example) for a
>> very long time yet - Xilinx have a long history of keeping old families
>> going for many many years after it was sensible to design them into new
>> systems.
>  
>> Developing... Spartan 3(and E,A,ADSP) was the last LUT4 generation, so
>> yes, I think it's stopped!
>
>>> I personally don't have enough overview about these two FPGA classes,
>>> so I can't see the detailed pros and cons.
>  
>> I'm not sure there's much to care about pros and cons.  LUT6 is here,
>> unless you want to design with relatively old chips.
>
> Argh. So all these valuable customers have to rework all parts of
> their highly optimized, huge module database, 

That's progress :)

This is how bare-metal-assembly-language programmers felt as processors
developed and their highly-tuned routines needed to be rewritten.  Of
course, the processors were faster and compilers were better, so the
smart ones just wrote straightforward, portable C-code which turned out
to be good-enough most of the time.  And that code was much more
re-usable.

> just because Xilinx engineers thought it might be less work for them
> to ever put LUT6 in silicon?

I'm sure it wasn't done on a whim!  There are sound business reasons for
how it's been done.  Sounds like they just don't fit what you'd like :(

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 153399
Subject: Re: LUT6 FPGAs and Carry Logic
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 16 Feb 2012 12:07:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
Martin Thompson <martin.j.thompson@trw.com> wrote:

(snip)
> Don't ask me - I'm not making the decisions.  Ultimately, Xilinx
> presumably decided it was a "win" in business terms: "We'll make the
> most money doing it this way."

Well, they do have some competition. If they don't design
and build what works for their customers, they will lose out.

>> I don't believe there's no market for LUT4 FPGAs using current 
>> silicon process.

> No-one is saying there is not a market.  Just that it's not 
> big enough for Xilinx to be targetting it.

As I understand it, 6LUT is better for larger chips.

For smaller ones, it likely doesn't make so much difference.
There is some advantage as far as synthesis software of
keeping a minimum number of different architectures.

Still, 4LUT chips should be around for a while.

-- glen



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