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 148150

Article: 148150
Subject: Help with VGA controller in Verilog
From: Giorgos Tzampanakis <gt67@hw.ac.uk>
Date: Wed, 23 Jun 2010 16:55:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
I've been trying to code a simple VGA controller to run on my 
Altera DE1 board. You can see my code here: 

http://pastebin.com/GMfxs6Xz

Note that my board has a DAC which converts the 4-bit digital 
signal for each of the RGB colors to the analog signal required 
by VGA. The timings are as found here for example: 

http://tinyvga.com/vga-timing/640x480@60Hz

When I run this code the monitor leaves the "No Signal Found" 
indication but it stays black no matter which color I choose.

I know that the board works because the VGA output works fine 
with the demonstration provided by Altera.

Any help greatly appreciated.

Article: 148151
Subject: Re: altshift_taps for Xilinx?
From: Sergio <checo22@gmail.com>
Date: Wed, 23 Jun 2010 10:50:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 23, 7:54=A0am, Gladys <yuhu...@gmail.com> wrote:
> I found that Xilinx provide an IP core called RAM-based Shift
> Register, the maximum depth is 1088, however, my image could have a
> high resolution of 3664 x 2748, which means I need a depth of 2748, is
> there any other methode to implement this? Thank you

There's a white paper from Xilinx titled "Implementing and Testing
Efficient Video Line Stores". It explains how to use Block RAMs as a
huge shift register of an arbitrary length. I've used the provided
examples with success in the past. You can find it here:
http://www.xilinx.com/products/boards/s3estarter/reference_designs.htm

Regards,
Sergio

Article: 148152
Subject: Re: Xilinx Timing Constraings
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Wed, 23 Jun 2010 19:14:47 +0100
Links: << >>  << T >>  << A >>
On Fri, 18 Jun 2010 10:27:03 -0700, Rob Gaddi wrote:

>I'm no luck figuring out how to implement the timing constraints for 
>something that, to my mind, ought to be pretty simple.
[source-synchronous timing, as pointed out by Gabor]

>I've gone through the Constraints Guide.  I've gone through UG612.  I've 
>gone through Austin's 5 part series over on the Xilinx forums.  And I'm 
>still lost.  Anyone have any revelations for me?

This is kinda easy to do with Altera Timequest.  There are
some distinctly non-trivial wrinkles with Timequest but,
whenever Ie tried it, I got really good results without
needing any manual-instantiation or set-dont-touch crud.

I'm slightly surprised that it's so hard to get X to do it.
But then it's always been a source of amazement to me that 
the documentation on UCF constraints language was so hard 
to get at.  Timequest documentation is only a little 
better, but tends to rely on the idea that people already 
know the Synopsys constraints language and can extrapolate
from that.  UCF is like nothing else, so nothing else helps.

<sigh of exasperation>
-- 
Jonathan Bromley

Article: 148153
Subject: Re: Help with VGA controller in Verilog
From: Gabor <gabor@alacron.com>
Date: Wed, 23 Jun 2010 13:22:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 23, 12:55=A0pm, Giorgos Tzampanakis <g...@hw.ac.uk> wrote:
> I've been trying to code a simple VGA controller to run on my
> Altera DE1 board. You can see my code here:
>
> http://pastebin.com/GMfxs6Xz
>
> Note that my board has a DAC which converts the 4-bit digital
> signal for each of the RGB colors to the analog signal required
> by VGA. The timings are as found here for example:
>
> http://tinyvga.com/vga-timing/640x480@60Hz
>
> When I run this code the monitor leaves the "No Signal Found"
> indication but it stays black no matter which color I choose.
>
> I know that the board works because the VGA output works fine
> with the demonstration provided by Altera.
>
> Any help greatly appreciated.


Have you simulated this?  Just looking quickly I don't see how
vga_hs works.  It looks like maybe your sync pulses are only
one clock long.  That won't drive any monitor I know of.

-- Gabor

Article: 148154
Subject: Re: altshift_taps for Xilinx?
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 23 Jun 2010 20:22:32 GMT
Links: << >>  << T >>  << A >>
Sergio <checo22@gmail.com> wrote:

>On Jun 23, 7:54=A0am, Gladys <yuhu...@gmail.com> wrote:
>> I found that Xilinx provide an IP core called RAM-based Shift
>> Register, the maximum depth is 1088, however, my image could have a
>> high resolution of 3664 x 2748, which means I need a depth of 2748, is
>> there any other methode to implement this? Thank you
>
>There's a white paper from Xilinx titled "Implementing and Testing
>Efficient Video Line Stores". It explains how to use Block RAMs as a
>huge shift register of an arbitrary length. I've used the provided
>examples with success in the past. You can find it here:
>http://www.xilinx.com/products/boards/s3estarter/reference_designs.htm

Such designs are actually circular buffers. Not very difficult to
create by yourself.

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

Article: 148155
Subject: Re: Why is Google so F****** dense about SPAM?
From: d_s_klein <d_s_klein@yahoo.com>
Date: Wed, 23 Jun 2010 14:13:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 22, 12:14=A0pm, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> On Tue, 22 Jun 2010 11:17:31 -0700 (PDT), martin_05
>
> <martin...@rocketmail.com> wrote:
> >> >you can create a group within "google groups" and moderate it. It is
> >> >"sponsored" by google-ads, which is nice. No banners, no popups, and
> >> >usually the ads are relevant to the content of the page being
> >> >currently viewed.
>
> >> So because of the spam-floods from googlegroups that render much of
> >> Usenet a less than happy experience for many users, one should move to
> >> googlegroups and put eyeballs on their sponsored advertisements? How
> >> nice of them to provide such a service...
>
> >No, I am talking about creating a set of forums on a privately owned
> >server that has nothing whatsoever to do with any of the FPGA
> >companies.
>
> Roger that. Replying to the suggestion to move to GoogleGroups.
>
> >It's a shame to see CAF and other valuable usenet lists get clobbered
> >with viagra and other crap. =A0My intent would be to create a nice clean
> >and professional environment that would be just as useful, if not more
> >due to newer technologies, than the usenet lists but devoid of trash.
>
> Take a look athttp://www.embeddedrelated.com/index.php, which gateways
> comp.arch.embedded to and from a web forum, for some ideas. There is
> minimal spam so I'd guess that their moderators or their upstream feed
> does do some housekeeping. The advantage is that it still has Usenet
> visibility, both ways.
>
> --
> Rich Webb =A0 =A0 Norfolk, VA

Yet another way Google can make money from spam.

"We are not evil" - yeah, right.

Article: 148156
Subject: Re: SDRAM capacity using Petalinux
From: d_s_klein <d_s_klein@yahoo.com>
Date: Wed, 23 Jun 2010 14:48:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 22, 7:35=A0am, "rduar002" <rduar002@n_o_s_p_a_m.fiu.edu> wrote:
> Hi,
> I successfully ported Petalinux on the XUPV5-LX110T FPGA board using 8 KB
> of Data/Instruction Cache. My SDRAM is 256 MB (MT4HTF3264HY-667F1). Howev=
er
> when I create a file (vi myFile) at the /var/tmp location, myFile cannot =
be
> bigger than 25 MB otherwise Petalinux will complain that my system is out
> of memory and it will log me off. Does anyone knows how to solve this
> issue. Any help will be greatly appreciated it.
>
> Petalinux version: 0.40-rc3
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

What does the command 'cat /proc/meminfo' tell you?  How about 'df' ??

Article: 148157
Subject: Re: Help with VGA controller in Verilog
From: Giorgos Tzampanakis <gt67@hw.ac.uk>
Date: Wed, 23 Jun 2010 23:01:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
Gabor <gabor@alacron.com> wrote in news:cc66c286-0547-416a-
9edf-3c43de9b7807@f8g2000vbl.googlegroups.com:

> Have you simulated this?  Just looking quickly I don't see 
how
> vga_hs works.  It looks like maybe your sync pulses are only
> one clock long.  That won't drive any monitor I know of.

I run it on the board and look at the signals using SignalTap 
or an external logic analyzer. It doesn't simulate correctly on 
the simulator, but the signals are as expected on the logic 
analyzer.

The pulses are not one clock long, notice:


case (next_state)
      `vertical_sync: begin
                         vga_vs <= 1'b0;
                         if (line_count ==     	    	    	    
	    	    	`max_vertical_sync_count && pulse_count ==     
	    	    	    	`max_pulse_count)
                         next_state <= `vertical_front_porch;
      end

etc...

So the low value on the sync pin will stay until the machine 
moves on to the next state. Why did you think that the pulse 
only stays for one clock cycle?

Article: 148158
Subject: Re: Help with VGA controller in Verilog
From: "jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Wed, 23 Jun 2010 20:59:13 -0500
Links: << >>  << T >>  << A >>
>I've been trying to code a simple VGA controller to run on my 
>Altera DE1 board. You can see my code here: 
>
>http://pastebin.com/GMfxs6Xz
>
>Note that my board has a DAC which converts the 4-bit digital 
>signal for each of the RGB colors to the analog signal required 
>by VGA. The timings are as found here for example: 
>
>http://tinyvga.com/vga-timing/640x480@60Hz
>
>When I run this code the monitor leaves the "No Signal Found" 
>indication but it stays black no matter which color I choose.
>
>I know that the board works because the VGA output works fine 
>with the demonstration provided by Altera.
>
>Any help greatly appreciated.
>

I simulated your code @ 25 Mhz after striping out the divider on clock_50
and
it shows:

4 us Horizontal pulse every 33.5 us
67.1 us Vertical pulse every 17.6 ms


Your running it at 15 hz

John

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

Article: 148159
Subject: Please suggest NON Volatile FPGA Devices
From: asimlink <asimlink@gmail.com>
Date: Wed, 23 Jun 2010 22:43:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Group,

Could you guys please recommend me a non volatile fpga (which can hold
its bit stream in, an on-chip flash).
I might need to put a soft core cpu in the fpga as well. so a medium
size device like Spartan-3AN-700 will be fine for me. I am looking for
any device which is smaller in size than Spartan-3AN-700 which is
23mmX23mm. Xilinx Spartan 3AN devices have no variety available in
terms of same packages but with different CLB sizes.

Regards,

Asim

Article: 148160
Subject: Re: Please suggest NON Volatile FPGA Devices
From: Gabor <gabor@alacron.com>
Date: Thu, 24 Jun 2010 07:06:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 24, 1:43=A0am, asimlink <asiml...@gmail.com> wrote:
> Hi Group,
>
> Could you guys please recommend me a non volatile fpga (which can hold
> its bit stream in, an on-chip flash).
> I might need to put a soft core cpu in the fpga as well. so a medium
> size device like Spartan-3AN-700 will be fine for me. I am looking for
> any device which is smaller in size than Spartan-3AN-700 which is
> 23mmX23mm. Xilinx Spartan 3AN devices have no variety available in
> terms of same packages but with different CLB sizes.
>
> Regards,
>
> Asim

You should check out the Lattice XP2 series.  They also offer
a 32-bit CPU development platform (Mico-32) and their chip
offerings are broader for non-volatile devices.  If you're
tied to Xilinx, then 3AN is your only choice.

Article: 148161
Subject: Re: Help with VGA controller in Verilog
From: Gabor <gabor@alacron.com>
Date: Thu, 24 Jun 2010 07:43:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 23, 7:01=A0pm, Giorgos Tzampanakis <g...@hw.ac.uk> wrote:
> Gabor <ga...@alacron.com> wrote in news:cc66c286-0547-416a-
> 9edf-3c43de9b7...@f8g2000vbl.googlegroups.com:
>
>
>
> > Have you simulated this? =A0Just looking quickly I don't see
> how
> > vga_hs works. =A0It looks like maybe your sync pulses are only
> > one clock long. =A0That won't drive any monitor I know of.
>
> I run it on the board and look at the signals using SignalTap
> or an external logic analyzer. It doesn't simulate correctly on
> the simulator, but the signals are as expected on the logic
> analyzer.
>
> The pulses are not one clock long, notice:
>
> case (next_state)
> =A0 =A0 =A0 `vertical_sync: begin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vga_vs <=3D 1'b0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (line_count =3D=3D =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 `max_vertical_sync_count =
&& pulse_count =3D=3D =A0 =A0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 `max_puls=
e_count)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0next_state <=3D `verti=
cal_front_porch;
> =A0 =A0 =A0 end
>
> etc...
>
> So the low value on the sync pin will stay until the machine
> moves on to the next state. Why did you think that the pulse
> only stays for one clock cycle?

As I said I only looked at it quickly and saw lines 74 and 75 setting
the sync pulses high (outside the state machine case statement), which
is something I usually do to create pulses.  Looking back at the code
I see that the value is assigned throughout the state.

If your monitor doesn't lock, you should make sure that the sync
signals
are actually reaching the sync pins of the monitor.  Also check if the
working version of the VGA code gives the same active level for the
sync pulses.  Most monitors use the sync active level as a code to
suggest a resolution standard.  This comes from the original VESA
definitions for PC video.  Getting it wrong doesn't usually prevent
the monitor from syncing, but your monitor may be more finicky.

Regards,
Gabor

Article: 148162
Subject: Re: Help with VGA controller in Verilog
From: Giorgos Tzampanakis <gt67@hw.ac.uk>
Date: Thu, 24 Jun 2010 15:09:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
"jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote
in news:0smdnezRz6VsJr_RnZ2dnUVZ_vednZ2d@giganews.com: 

> I simulated your code @ 25 Mhz after striping out the
> divider on clock_50 and
> it shows:
> 
> 4 us Horizontal pulse every 33.5 us
> 67.1 us Vertical pulse every 17.6 ms
> 
> 
> Your running it at 15 hz
> 

These times look about correct based on http://tinyvga.com/vga-
timing/640x480@60Hz .

Am I missing something? The page says these are the 60 Hz 
timings.

Article: 148163
Subject: Re: Help with VGA controller in Verilog
From: Giorgos Tzampanakis <gt67@hw.ac.uk>
Date: Thu, 24 Jun 2010 15:17:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
Gabor <gabor@alacron.com> wrote in
news:2b315a7b-decf-407a-a018-97425e869103@c10g2000yqi.googlegro
ups.com: 

> If your monitor doesn't lock, you should make sure that the
> sync signals
> are actually reaching the sync pins of the monitor.  Also
> check if the working version of the VGA code gives the same
> active level for the sync pulses.  Most monitors use the
> sync active level as a code to suggest a resolution
> standard.  This comes from the original VESA definitions for
> PC video.  Getting it wrong doesn't usually prevent the
> monitor from syncing, but your monitor may be more finicky. 
> 

I will check those suggestions, but I have no control over the 
level, I can only set it to 0 or 1 within the fpga, so it's 
unlikely that there is some problem there, given that the demo 
program runs fine.

Article: 148164
Subject: Re: Help with VGA controller in Verilog
From: Giorgos Tzampanakis <gt67@hw.ac.uk>
Date: Thu, 24 Jun 2010 19:22:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
Giorgos Tzampanakis <gt67@hw.ac.uk> wrote in
news:Xns9DA0B66A6D054fdnbgui7uhu5h8hrnuio@188.40.43.230: 

> I've been trying to code a simple VGA controller to run on
> my Altera DE1 board. You can see my code here: 
> 
> http://pastebin.com/GMfxs6Xz
> 
> Note that my board has a DAC which converts the 4-bit
> digital signal for each of the RGB colors to the analog
> signal required by VGA. The timings are as found here for
> example: 
> 
> http://tinyvga.com/vga-timing/640x480@60Hz
> 
> When I run this code the monitor leaves the "No Signal
> Found" indication but it stays black no matter which color I
> choose. 
> 
> I know that the board works because the VGA output works
> fine with the demonstration provided by Altera.
> 
> Any help greatly appreciated.

Fixed. The problem was that I was only driving the horizontal 
sync pulses while the pixel rgb values were driven.

Article: 148165
Subject: Re: Help with VGA controller in Verilog
From: Gabor <gabor@alacron.com>
Date: Thu, 24 Jun 2010 13:39:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 24, 11:17=A0am, Giorgos Tzampanakis <g...@hw.ac.uk> wrote:
> Gabor <ga...@alacron.com> wrote innews:2b315a7b-decf-407a-a018-97425e8691=
03@c10g2000yqi.googlegro
> ups.com:
>
> > If your monitor doesn't lock, you should make sure that the
> > sync signals
> > are actually reaching the sync pins of the monitor. =A0Also
> > check if the working version of the VGA code gives the same
> > active level for the sync pulses. =A0Most monitors use the
> > sync active level as a code to suggest a resolution
> > standard. =A0This comes from the original VESA definitions for
> > PC video. =A0Getting it wrong doesn't usually prevent the
> > monitor from syncing, but your monitor may be more finicky.
>
> I will check those suggestions, but I have no control over the
> level, I can only set it to 0 or 1 within the fpga, so it's
> unlikely that there is some problem there, given that the demo
> program runs fine.

What I meant by "levels" was active high vs active low, not the
actual voltage which should be TTL.  Anyway glad to see you've
got it fixed.

regards,
Gabor

Article: 148166
Subject: Re: Help with VGA controller in Verilog
From: "jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 24 Jun 2010 17:50:08 -0500
Links: << >>  << T >>  << A >>
>"jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote
>in news:0smdnezRz6VsJr_RnZ2dnUVZ_vednZ2d@giganews.com: 
>
>> I simulated your code @ 25 Mhz after striping out the
>> divider on clock_50 and
>> it shows:
>> 
>> 4 us Horizontal pulse every 33.5 us
>> 67.1 us Vertical pulse every 17.6 ms
>> 
>> 
>> Your running it at 15 hz
>> 
>
>These times look about correct based on http://tinyvga.com/vga-
>timing/640x480@60Hz .
>
>Am I missing something? The page says these are the 60 Hz 
>timings.
>
My Bad. I grabbed the wrong number when I divided.

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

Article: 148167
Subject: Re: Please suggest NON Volatile FPGA Devices
From: -jg <jim.granville@gmail.com>
Date: Thu, 24 Jun 2010 15:52:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 24, 5:43=A0pm, asimlink <asiml...@gmail.com> wrote:
> Hi Group,
>
> Could you guys please recommend me a non volatile fpga (which can hold
> its bit stream in, an on-chip flash).
> I might need to put a soft core cpu in the fpga as well. so a medium
> size device like Spartan-3AN-700 will be fine for me. I am looking for
> any device which is smaller in size than Spartan-3AN-700 which is
> 23mmX23mm. Xilinx Spartan 3AN devices have no variety available in
> terms of same packages but with different CLB sizes.

The usual suspects would be Lattice, Actel, SiliconBlue and if you
don't need it today  ;)  then even Menta who have a MRAM based FPGA
coming...

http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=3D225600023

If you can shrink the fpga by avoiding the soft-cpu, then Cypress and
Actel have Arm+Logic solutions

-jg


Article: 148168
Subject: fooling the compiler
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 24 Jun 2010 22:09:33 -0700
Links: << >>  << T >>  << A >>


We have a Spartan6/45 that's talking to 16 separate SPI A/D
converters. The data we get back is different, but the clock and chip
select timings are the same. To get the timing right, avoiding routing
delays, we need our outgoing stuff to be reclocked by i/o cell
flipflops.

So what happens is that we have one state machine running all 16 SPI
interfaces. We tell the software that we want the adc chip select
flops in i/o cells. The compiler decides that all are seeing the same
input signal, so reduces them to one flipflop. Then it concludes that
that flipflop can't be in an i/o block, and builds it that way. The
resulting routing delays are deadly.

We couldn't find a way to force these 16 flops into IOBs. Really.

The fix is to fool the compiler into thinking the flipflop states are
not the same. Turns out the the synchronous clear inputs to the flops
are unused in our design. My suggestion was to ground an input pin,
run that into the serial input of a 16-bit shift register, and route
the sr taps to the clears of the 16 output flops. The compiler can't
know that these levels are in fact always low, so has to gen 16
different flops. *Then* it allows the flops to be forced into IOBs.

Rob has a better idea, just make a 16-bit SR that generates a
thermometer code on powerup, namely walk a 1 into it, and have the sr
output bits un-clear the i/o flops sequentially. The compiler isn't
smart enough catch onto that, and we don't need to ground a pin.

It works.

Isn't that all perfectly stupid?

The Altera folks are coming to make their pitch tomorrow. This story
may amuse them.

John



Article: 148169
Subject: Re: fooling the compiler
From: Sylvia Else <sylvia@not.here.invalid>
Date: Fri, 25 Jun 2010 15:34:20 +1000
Links: << >>  << T >>  << A >>
On 25/06/2010 3:09 PM, John Larkin wrote:

> Rob has a better idea, just make a 16-bit SR that generates a
> thermometer code on powerup, namely walk a 1 into it, and have the sr
> output bits un-clear the i/o flops sequentially. The compiler isn't
> smart enough catch onto that, and we don't need to ground a pin.

The compiler isn't smart enough in its current version. You may be 
laying a trap for the future if you use a technique that relies on the 
compiler not performing an analysis that it could perform in principle, 
but just doesn't at the moment.

I suppose it doesn't matter if you sure that neither this circuit, nor 
any variant of it, will ever be processed by a newer version of the 
compiler.

Sylvia.

Article: 148170
Subject: Re: fooling the compiler
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 25 Jun 2010 07:05:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Sylvia Else <sylvia@not.here.invalid> wrote:
> On 25/06/2010 3:09 PM, John Larkin wrote:
 
>> Rob has a better idea, just make a 16-bit SR that generates a
>> thermometer code on powerup, namely walk a 1 into it, and have the sr
>> output bits un-clear the i/o flops sequentially. The compiler isn't
>> smart enough catch onto that, and we don't need to ground a pin.
 
> The compiler isn't smart enough in its current version. You may be 
> laying a trap for the future if you use a technique that relies on the 
> compiler not performing an analysis that it could perform in principle, 
> but just doesn't at the moment.

That could only happen if the compiler figured out that you 
weren't looking at the output for the first 16 cycles. 
You can know that, but normally the compiler can't assume that.

That is, with the assumption that the SR initializes to zero and
clocks a 1 in.

-- glen 

Article: 148171
Subject: Re: fooling the compiler
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Fri, 25 Jun 2010 08:46:30 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga John Larkin 
<jjlarkin@highnotlandthistechnologypart.com> wrote:


> We have a Spartan6/45 that's talking to 16 separate SPI A/D
> converters. The data we get back is different, but the clock and chip
> select timings are the same. To get the timing right, avoiding routing
> delays, we need our outgoing stuff to be reclocked by i/o cell
> flipflops.

> So what happens is that we have one state machine running all 16 SPI
> interfaces. We tell the software that we want the adc chip select
> flops in i/o cells. The compiler decides that all are seeing the same
> input signal, so reduces them to one flipflop. Then it concludes that
> that flipflop can't be in an i/o block, and builds it that way. The
> resulting routing delays are deadly.

> We couldn't find a way to force these 16 flops into IOBs. Really.

> The fix is to fool the compiler into thinking the flipflop states are
> not the same. Turns out the the synchronous clear inputs to the flops
> are unused in our design. My suggestion was to ground an input pin,
> run that into the serial input of a 16-bit shift register, and route
> the sr taps to the clears of the 16 output flops. The compiler can't
> know that these levels are in fact always low, so has to gen 16
> different flops. *Then* it allows the flops to be forced into IOBs.

> Rob has a better idea, just make a 16-bit SR that generates a
> thermometer code on powerup, namely walk a 1 into it, and have the sr
> output bits un-clear the i/o flops sequentially. The compiler isn't
> smart enough catch onto that, and we don't need to ground a pin.

> It works.

> Isn't that all perfectly stupid?

Did you try to attach a 
(* KEEP = "TRUE" *)
attribute to the registers in question?

I had a similar problem with registers meant to get places in an IOB
absorbed by the feeding BRAM


-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 148172
Subject: Re: fooling the compiler
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 25 Jun 2010 03:31:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 25, 1:09=A0am, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>
> We couldn't find a way to force these 16 flops into IOBs. Really.

In Synplify, this common type of situation is easily handled with the
"syn_preserve" directive which is different than Synplify's "keep"
used for wires in my Verilog code.

It's good to get intimate with your compiler's list of attributes and
directives.  While it's often "pushing the rope" to get the results
you expect, it's good to become more expert at pushing.

- John_H

Article: 148173
Subject: Re: fooling the compiler
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Fri, 25 Jun 2010 05:32:01 -0500
Links: << >>  << T >>  << A >>
I would be amazed if you cant get XST to keep all 16 flipflops. I know you
can do it in Synplify.

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

Article: 148174
Subject: Re: fooling the compiler
From: Philipp Klaus Krause <pkk@spth.de>
Date: Fri, 25 Jun 2010 14:26:35 +0200
Links: << >>  << T >>  << A >>
Am 25.06.2010 12:31, schrieb John_H:
> On Jun 25, 1:09 am, John Larkin
> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>>
>> We couldn't find a way to force these 16 flops into IOBs. Really.
> 
> In Synplify, this common type of situation is easily handled with the
> "syn_preserve" directive which is different than Synplify's "keep"
> used for wires in my Verilog code.

Hmm, but is there a portable way to do these things? Something like C's
"volatile"?

Philipp




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