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 125250

Article: 125250
Subject: Re: What to consider for source synchronous clocking?
From: "David Spencer" <davidmspencer@verizon.net>
Date: Thu, 18 Oct 2007 15:26:21 GMT
Links: << >>  << T >>  << A >>
> I'm using a Spartan 3 right now, and I'm trying to provide source
> synchronous clock clocking to a SDR SDRAM using DDR register.
> The component looks something like this:

I'm not sure if it's possible in your design, but by far the simplest 
solution would be to use a single external clock that drives both the SDRAM 
and all your FPGA logic (through a clock buffer if necessary). If you must 
derive the SDRAM clock from the FPGA then one thing you can do is drive out 
the derived clock from an I/O and feed it to both the SDRAM and loopback to 
an FPGA clock pin (again using a buffer if needed). Both of these approaches 
avoid having to worry about IOB delays in the clock output.



Article: 125251
Subject: Re: FPGA pin swapping utility
From: Sean Durkin <news_oct07@durkin.de>
Date: Thu, 18 Oct 2007 17:44:10 +0200
Links: << >>  << T >>  << A >>
cpandya@yahoo.com wrote:
> We are using V5LX110T and V5L330 FPGAs.  Are there decent pin swapping
> utilities so that we do not have to spend a lot of time in PCB Laout
> to do the pin swapping?  I am hoping that the tool shows the BGA view
> of the FPGA and lets the user to swap pins such that there is good
> break out from the FPGA.
Mentor's "IO Designer" does just that. You use it to create schematic
symbols that can be changed dynamically. So you can finish the schematic
and change just the symbols later when optimizing the pin out.

You can import your PCB-Layout (after all components are placed) and use
IO-Designer to "unravel" busses and optimize the pinout.

It also knows about bank supply voltage rules, clock pins/regions and so
on (so it won't let you put an LVCMOS18-output in a bank that already
has a LVTTL-Output or let you put a clock on a regular IO), which can be
a big help.

It can also generate a conatraint file for your FPGA (UCF or SDC) and a
top level HDL-file.

But as all Mentor products it's quite expensive and has its quirks...

HTH,
Sean

-- 
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

Article: 125252
Subject: Fast Sampling of digital signals
From: aravind <aramosfet@gmail.com>
Date: Thu, 18 Oct 2007 09:03:48 -0700
Links: << >>  << T >>  << A >>
Hi,
     I'm building a S/PDIF Receiver for implementation on spartan 3
fpga. I don't have an expensive DSO to analyze the spdif signals :
(   So i decided to build a sampler and run it fast enough, say 10-20
times the spdif signal frequency and the display the signal on some
audio editing software.(remember i'm sampling only digital signals so
there's no ADC involved)

So here's my setup, I'm taking the input signal and passing it through
a 2 flop synchroniser, then i'm packing 8 samples to a byte and
writing it to a 16K block ram fifo on fpga. The sampled data is sent
to the PC through FTDI's UM245R module. At reset the sampler samples
16K X 8 samples , writes to fifo and stops. the system is running at
50Mhz (also sampling input signal at 50msps), the sampling packing and
writing to fifo is done on the fly. Then the usb module writes the
data to the usb port in its own time.

The problem:
    When i sample signals from the same clock domain (i.e, a divided
clock from 50Mhz sys clk)
the are no problems. I see perfect clock signal with nearly 50% duty
cycle and no glitches in sight. but once i feed an external signal
signal such as the spdif or a clock from a different oscillator, the
signal seems to closely match the frequency of the input but I see a
lot of glitches. Most of the glitches are one sample wide and very
close to the rising/falling edges of the input signal. but there are
also quite a few glitches in stable 1's /0's regions of the input
signal.

   So what could be the possible cause of these glitches? I can
understand glitches near the edges which could be due to metastability
but in the middle of stable 1's and 0's there could be no issue of
metastability. I have used 2 flop synchroniser like the ones used in
asynchronous fifo's. What else can i do the eliminate the glitches?


Article: 125253
Subject: Re: Fast Sampling of digital signals
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 18 Oct 2007 09:23:10 -0700
Links: << >>  << T >>  << A >>
Metastability is not your problem.
At a 50 MHz clock rate, it will be millions of years between any
occurance of metastable delays that stretch over most of a clock
period.
Peter Alfke

On Oct 18, 9:03 am, aravind <aramos...@gmail.com> wrote:
> Hi,
>      I'm building a S/PDIF Receiver for implementation on spartan 3
> fpga. I don't have an expensive DSO to analyze the spdif signals :
> (   So i decided to build a sampler and run it fast enough, say 10-20
> times the spdif signal frequency and the display the signal on some
> audio editing software.(remember i'm sampling only digital signals so
> there's no ADC involved)
>
> So here's my setup, I'm taking the input signal and passing it through
> a 2 flop synchroniser, then i'm packing 8 samples to a byte and
> writing it to a 16K block ram fifo on fpga. The sampled data is sent
> to the PC through FTDI's UM245R module. At reset the sampler samples
> 16K X 8 samples , writes to fifo and stops. the system is running at
> 50Mhz (also sampling input signal at 50msps), the sampling packing and
> writing to fifo is done on the fly. Then the usb module writes the
> data to the usb port in its own time.
>
> The problem:
>     When i sample signals from the same clock domain (i.e, a divided
> clock from 50Mhz sys clk)
> the are no problems. I see perfect clock signal with nearly 50% duty
> cycle and no glitches in sight. but once i feed an external signal
> signal such as the spdif or a clock from a different oscillator, the
> signal seems to closely match the frequency of the input but I see a
> lot of glitches. Most of the glitches are one sample wide and very
> close to the rising/falling edges of the input signal. but there are
> also quite a few glitches in stable 1's /0's regions of the input
> signal.
>
>    So what could be the possible cause of these glitches? I can
> understand glitches near the edges which could be due to metastability
> but in the middle of stable 1's and 0's there could be no issue of
> metastability. I have used 2 flop synchroniser like the ones used in
> asynchronous fifo's. What else can i do the eliminate the glitches?



Article: 125254
Subject: Error using SOPC builder - "Custom SDRAM" with 8-bits gives error with Signal "az_be_n"
From: sendthis@gmail.com
Date: Thu, 18 Oct 2007 09:39:09 -0700
Links: << >>  << T >>  << A >>
I'm trying to make a SDRAM controller with SOPC builder, but when I
change the data width to 8bits I get the following error..

Warning: Signal "az_be_n" of type "byteenable_n" and width 1 must have
width of 2, 4, 8, 16, 32, 64, 128.

I'm trying to make the system for a 64Mb SDR SDRAM, Micron
MT48LC8M8A2P-75.

Even when I select the Alliance AS4LC2M8S0-10 chip it does the same
thing. So I'm guessing it has to do with a width of 8 bits.

Thank you,
Eric


Article: 125255
Subject: Wishbone Specification in Action
From: Gilbates <nana.asante@gmail.com>
Date: Thu, 18 Oct 2007 16:46:18 -0000
Links: << >>  << T >>  << A >>
Hi all!

I have gone through the WISHBONE Specification for open-core ip SoC. I
do understand the detail in there, however, I am lost as to how to
implement the standard. I'd like to use the bus a communication
framework for a set of  softcore-instruments.

Anyone with an example of how the specification can be translated into
implementation?

Thanks!


Article: 125256
Subject: Re: Fast Sampling of digital signals
From: cs_posting@hotmail.com
Date: Thu, 18 Oct 2007 09:50:29 -0700
Links: << >>  << T >>  << A >>
On Oct 18, 12:03 pm, aravind <aramos...@gmail.com> wrote:

> but once i feed an external signal
> signal such as the spdif or a clock from a different oscillator, the
> signal seems to closely match the frequency of the input but I see a
> lot of glitches. Most of the glitches are one sample wide and very
> close to the rising/falling edges of the input signal. but there are
> also quite a few glitches in stable 1's /0's regions of the input
> signal.

When working with SPDIF I wouldn't rule out analog effects, especially
transmission line effects.  And not just on your end, some of the
sources are pretty ugly.

Did some digital audio work and found a couple systems where playing
with the terminating resistor would make all the difference between
reliable operation, iffy operation, and completely inoperative.  Some
of that turned out to be a suboptimal manufacturer configuration of
the clock recovery device making it hypersensitive to duty cycle, but
the analog quality of the signal could make it work or fail.


Article: 125257
Subject: Re: Wishbone Specification in Action
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 18 Oct 2007 10:01:57 -0700
Links: << >>  << T >>  << A >>
"Gilbates" <nana.asante@gmail.com> wrote in message 
news:1192725978.602247.25610@q5g2000prf.googlegroups.com...
>
> Anyone with an example of how the specification can be translated into
> implementation?
>
> Thanks!
>
http://www.opencores.org/ 



Article: 125258
Subject: Re: Fast Sampling of digital signals
From: aravind <aramosfet@gmail.com>
Date: Thu, 18 Oct 2007 10:03:55 -0700
Links: << >>  << T >>  << A >>
On Oct 18, 9:50 pm, cs_post...@hotmail.com wrote:
> On Oct 18, 12:03 pm, aravind <aramos...@gmail.com> wrote:
>
> > but once i feed an external signal
> > signal such as the spdif or a clock from a different oscillator, the
> > signal seems to closely match the frequency of the input but I see a
> > lot of glitches. Most of the glitches are one sample wide and very
> > close to the rising/falling edges of the input signal. but there are
> > also quite a few glitches in stable 1's /0's regions of the input
> > signal.
>
> When working with SPDIF I wouldn't rule out analog effects, especially
> transmission line effects.  And not just on your end, some of the
> sources are pretty ugly.
>
> Did some digital audio work and found a couple systems where playing
> with the terminating resistor would make all the difference between
> reliable operation, iffy operation, and completely inoperative.  Some
> of that turned out to be a suboptimal manufacturer configuration of
> the clock recovery device making it hypersensitive to duty cycle, but
> the analog quality of the signal could make it work or fail.

Ok, I agree i did use a fairly long cable to bring the spdif signal
from the PC, but i have the same problem when i feed a ~1Mhz clock
straight off an oscillator.


Article: 125259
Subject: mess around with supply voltage to cyclone III
From: fpgazone@gmail.com
Date: Thu, 18 Oct 2007 17:25:53 -0000
Links: << >>  << T >>  << A >>
Hi,

I have a Cyclone III FPGA. I have created a circuit on it whose
performance I want to observe under the influence of supply voltage
variations and glitches.

I want to create intentional glitches of this cyclone iii development
board. Any ideas?

-PrincessGateArray.


Article: 125260
Subject: Re: Fast Sampling of digital signals
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 18 Oct 2007 10:29:42 -0700
Links: << >>  << T >>  << A >>
You can simplify your system:
Eliminate the FIFO controller, and write bit-serial data into one BRAM
port, and read byte-wide data from the other port.
You just need two counters, one longer one for write, and a shorter
one for read.

To trace mysterious errors, I always reduce complexity to "bare
bones..."
Peter Alfke

On Oct 18, 10:03 am, aravind <aramos...@gmail.com> wrote:
> On Oct 18, 9:50 pm, cs_post...@hotmail.com wrote:
>
>
>
> > On Oct 18, 12:03 pm, aravind <aramos...@gmail.com> wrote:
>
> > > but once i feed an external signal
> > > signal such as the spdif or a clock from a different oscillator, the
> > > signal seems to closely match the frequency of the input but I see a
> > > lot of glitches. Most of the glitches are one sample wide and very
> > > close to the rising/falling edges of the input signal. but there are
> > > also quite a few glitches in stable 1's /0's regions of the input
> > > signal.
>
> > When working with SPDIF I wouldn't rule out analog effects, especially
> > transmission line effects.  And not just on your end, some of the
> > sources are pretty ugly.
>
> > Did some digital audio work and found a couple systems where playing
> > with the terminating resistor would make all the difference between
> > reliable operation, iffy operation, and completely inoperative.  Some
> > of that turned out to be a suboptimal manufacturer configuration of
> > the clock recovery device making it hypersensitive to duty cycle, but
> > the analog quality of the signal could make it work or fail.
>
> Ok, I agree i did use a fairly long cable to bring the spdif signal
> from the PC, but i have the same problem when i feed a ~1Mhz clock
> straight off an oscillator.



Article: 125261
Subject: Re: FPGA pin swapping utility
From: ghelbig@gmail.com
Date: Thu, 18 Oct 2007 17:40:27 -0000
Links: << >>  << T >>  << A >>
On Oct 18, 8:20 am, cpan...@yahoo.com wrote:
> We are using V5LX110T and V5L330 FPGAs.  Are there decent pin swapping
> utilities so that we do not have to spend a lot of time in PCB Laout
> to do the pin swapping?  I am hoping that the tool shows the BGA view
> of the FPGA and lets the user to swap pins such that there is good
> break out from the FPGA.
>
> Thanks.
>
> CP

In my experience, setting up the automated tool has taken longer than
"just doing it".

My design flow is OrCAD->(Q2/ISE)->PADS.  I go into ECO mode in Pads,
and clean up the routes, part data sheet in hand.  I take the "was-is"
file from PADS, and translate it into a pin-swap file for OrCAD, and
then update the pinout (constraint) file for the FPGA..  After a
couple of boards, I've learned how to "see" the routes (ie BGA->QFP)
when pinning the FPGA, so it typically takes only two passes to get it
right.

Truth is, I would have trouble trusting a low-end tool to get it
right; I've seen the Mentor tool make mistakes (mostly from pinswap
parameters being entered wrong, but a mistake is a mistake.)

G.


Article: 125262
Subject: Re: R: Xilinx:is it possible to install Impact 9.1only?
From: ghelbig@gmail.com
Date: Thu, 18 Oct 2007 17:43:28 -0000
Links: << >>  << T >>  << A >>
On Oct 16, 11:34 am, "blisca" <bliscachiocciolinatiscali.it> wrote:
> <cs_post...@hotmail.com> wrote in message
>
> 1192554870.585680.195...@k35g2000prh.googlegroups.com...> On Oct 16, 2:33 am, "blisca" <bliscachiocciolinatiscali.it> wrote:
>
> > > Is it possible to download and install only the newest Impact version?
> > > Thanks once more
>
> > I think so... I think I remember something about a lab install or
> > technician install or something, that could only program files but not
> > compile them
>
> thanks for this trace,i'll try to follow it

It's called "ISE WebPACK - Lab Install", and is available from <http://
www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=12740>


Article: 125263
Subject: Re: Wishbone Specification in Action
From: Patrick Dubois <prdubois@gmail.com>
Date: Thu, 18 Oct 2007 17:47:06 -0000
Links: << >>  << T >>  << A >>
On 18 oct, 12:46, Gilbates <nana.asa...@gmail.com> wrote:
> Hi all!
>
> I have gone through the WISHBONE Specification for open-core ip SoC. I
> do understand the detail in there, however, I am lost as to how to
> implement the standard. I'd like to use the bus a communication
> framework for a set of  softcore-instruments.
>
> Anyone with an example of how the specification can be translated into
> implementation?
>
> Thanks!

Take a look at this file:
http://www.pldworld.com/_hdl/2/_ip/-silicore.net/pdfiles/wishbone/misc/WBVHDLIB.zip

It contains basic building blocks (memory, registers, bus arbiter) and
has some examples of complete (small) designs.

Cheers,
Patrick


Article: 125264
Subject: Re: FPGA pin swapping utility
From: Andy <jonesandy@comcast.net>
Date: Thu, 18 Oct 2007 10:54:19 -0700
Links: << >>  << T >>  << A >>
On Oct 18, 10:44 am, Sean Durkin <news_oc...@durkin.de> wrote:
> cpan...@yahoo.com wrote:
> > We are using V5LX110T and V5L330 FPGAs.  Are there decent pin swapping
> > utilities so that we do not have to spend a lot of time in PCB Laout
> > to do the pin swapping?  I am hoping that the tool shows the BGA view
> > of the FPGA and lets the user to swap pins such that there is good
> > break out from the FPGA.
>
> Mentor's "IO Designer" does just that. You use it to create schematic
> symbols that can be changed dynamically. So you can finish the schematic
> and change just the symbols later when optimizing the pin out.
>
> You can import your PCB-Layout (after all components are placed) and use
> IO-Designer to "unravel" busses and optimize the pinout.
>
> It also knows about bank supply voltage rules, clock pins/regions and so
> on (so it won't let you put an LVCMOS18-output in a bank that already
> has a LVTTL-Output or let you put a clock on a regular IO), which can be
> a big help.
>
> It can also generate a conatraint file for your FPGA (UCF or SDC) and a
> top level HDL-file.
>
> But as all Mentor products it's quite expensive and has its quirks...
>
> HTH,
> Sean
>
> --
> My email address is only valid until the end of the month.
> Try figuring out what the address is going to be after that...

For Cadence Allegro Design Entry (aka ConceptHDL), we use a "bit-
sliced" symbol where each IO pin has a common Vcco pin. You can hard-
assign pin numbers you need, and let Allegro (board layout) auto or
manually swap the remaining pins. Having the common Vcco pins keeps
Allegro from swapping IO pins that have their Vcco pin tied to a
different voltage (or just signal name). The advantage of this
approach is if you have multiple banks powered from one voltage, you
can swap freely between IO pins in any of those banks.  You can lock
IO pins into specific banks by temporarily assigning a unique signal
name to that bank's Vcco pins. Then when you're done swapping, tie all
the appropriate banks' Vcco pins to the correct voltage signal.

This works very well as far as it goes, but it does not allow you to
constrain smaller groups of pins (say around local clocks, etc.), but
still allow swappability within those smaller groups.

Andy


Article: 125265
Subject: Re: FPGA pin swapping utility
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 19 Oct 2007 07:34:50 +1300
Links: << >>  << T >>  << A >>
ghelbig@gmail.com wrote:
> On Oct 18, 8:20 am, cpan...@yahoo.com wrote:
> 
>>We are using V5LX110T and V5L330 FPGAs.  Are there decent pin swapping
>>utilities so that we do not have to spend a lot of time in PCB Laout
>>to do the pin swapping?  I am hoping that the tool shows the BGA view
>>of the FPGA and lets the user to swap pins such that there is good
>>break out from the FPGA.
>>
>>Thanks.
>>
>>CP
> 
> 
> In my experience, setting up the automated tool has taken longer than
> "just doing it".
> 
> My design flow is OrCAD->(Q2/ISE)->PADS.  I go into ECO mode in Pads,
> and clean up the routes, part data sheet in hand.  I take the "was-is"
> file from PADS, and translate it into a pin-swap file for OrCAD, and
> then update the pinout (constraint) file for the FPGA..  After a
> couple of boards, I've learned how to "see" the routes (ie BGA->QFP)
> when pinning the FPGA, so it typically takes only two passes to get it
> right.
> 
> Truth is, I would have trouble trusting a low-end tool to get it
> right; I've seen the Mentor tool make mistakes (mostly from pinswap
> parameters being entered wrong, but a mistake is a mistake.)

  You can also use scripts in PADS to (relatively easily) scan the FPGA
and export a revised Pinout to the FPGA tools. You then confirm that
is routable in the FPGA/CPLD tool flow.
  Only design constraint is you need to match the NET names to the fpGA 
signal names, but who doesn't do that ? :)

-jg


Article: 125266
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 19 Oct 2007 08:01:43 +1300
Links: << >>  << T >>  << A >>
Antti wrote:

> Ok, this time it looks like solved. feel sosososoo stuuupid.
> of course the internal skew of clocks is important, so adding manually
> a global clock buffer seem have cured that. still pending of longer
> testing, but it looks like ok now.

So you are saying that todays FPGA fabrics (which one again here ?)
now have such routing delays, (and fast registers) that Tco is less
than Troute, and can violate Tsu/Th ?

Maybe a longer shifter literally takes more room, so statistically
has more chance of long/short routes in the wrong combination  ?

If you run post route sim, does that flag any issues
- ideally it should, right :)

-jg



Article: 125267
Subject: Re: VHDL trivia?
From: "evilkidder@googlemail.com" <evilkidder@googlemail.com>
Date: Thu, 18 Oct 2007 19:17:21 -0000
Links: << >>  << T >>  << A >>
>
> Although I think the case statement approach probably synthesizes a
> lot nicer, and is much nicer code. I'm pretty sure this will
> synthesize, but I'd build a test module with small vectors first and
> check the RTL viewer to make sure it turns into something that makes
> sense.

Hi,

Shown below is a HDFS binary to onehot convertor which can generate
VHDL or Verilog designs for any width input.

The first one generates a case statement - it's the one I would use if
I were writing the code in VHDL and I'd assume it would produce the
best implementation.  The second one generates a structural
implementation using multiplexors and or gates.  I wouldn't even
consider writing this by hand.  However, for a 16 bit onehot input,
the case statement version requires 39 luts, while the structural
version needs just 12 luts.  The difference lies in how the two
versions deal with invalid inputs, though I was very surprised at just
how big that difference was.

Cheers,

Andy
http://code.google.com/p/hdfs/

compile:
> fsc -r hdfs.dll -r hdfslib.dll b21h.ml

case statement version, 56 bit one hot input vector, verilog out
> b21h.exe behave verilog 56

structural version, 16 bit one hot input vector, vhdl out
> b21h.exe struct vhdl 16

(* binary to one hot circuit, VHDL/Verilog generator and simulator *)

#light
open DigitalLogic
open Numeric.Ops
open Signal

(* convert one hot vector to binary.  Behavioural implementation using
a case statement.
   If the one hot vector is invalid  (zero or more than one bit is
set) then the output is set to zero *)
let onehot_to_binary_b onehot =
  let owidth = width onehot
  let bwidth = Util.clog2 (owidth-1)
  let binary = b_wire0 bwidth
  let match_case n m = [ for i in 0 .. n-1 -> if (n-i-1)=m then "1"
else "0" ] |> String.concat ""
  behave
    [
      b_switch onehot
        [ for i in { 0 .. owidth-1 } -> b_case (constb (match_case
owidth i)) [ binary $== consti bwidth i ] ]
    ];
  binary.q

(* convert one hot vector to binary.  Structural implementation using
multiplexors.
   Behaviour is undefined if the one hot vector is invalid - at a
rough guess, 0 in 0 out, otherwise
   the highest set bit is chosen *)
let onehot_to_binary_s onehot =
  let owidth = width onehot in
  let bwidth = Util.clog2 (owidth-1) in
  let rec split_and_mux onehot value =
    match width onehot with
    | 1 -> consti bwidth value, onehot
    | n when n>0 ->
      let hi,lo = split onehot
      let (hi,hictrl),(lo,loctrl) = split_and_mux hi (value + width
lo), split_and_mux lo value
      hictrl.mux2(hi, lo), (hictrl ||| loctrl)
    | _ -> failwith "split_and_mux error"
  fst (split_and_mux onehot 0)

let argv =
#if INTERACTIVE
  fsi.CommandLineArgs
#else
  Sys.argv
#endif

let gen_onehot_to_binary core_type hdl onehot_bits =
  (* build circuit *)
  let onehot = input "onehot" onehot_bits
  let onehot_to_binary =
    match core_type with
    | "behave" -> onehot_to_binary_b
    | "struct" -> onehot_to_binary_s
    | _ -> failwith "Invalid core type"
  let write,ext =
    match hdl with
    | "vhdl" -> Vhdl.write, ".vhd"
    | "verilog" -> Verilog.write, ".v"
    | _ -> failwith "Invalid hdl type"
  let circuit = [ (onehot_to_binary onehot).output "binary" ] |>
Circuit.create
  (* write hdl *)
  Circuit.write_file write "" ("onehot_to_binary_" ^ core_type ^ "_" ^
string_of_int onehot_bits) ext circuit
  (* simulate *)
  let sim,data = (Simulator.create circuit).record
  sim.reset
  let binary n m = [ for i in 0 .. n-1 -> if (n-i-1)=m then "1" else
"0" ] |> String.concat ""
  for i=0 to onehot_bits-1 do
    sim.[onehot].b <- binary onehot_bits i
    sim.cycle
  Waveform.draw2 data Waveform.HexFormat

do gen_onehot_to_binary argv.(1) argv.(2) (int_of_string argv.(3))

********************************* example output

--------------------------------------------------------
-- Generated by HDFS version 0.2.1
-- http://code.google.com/p/hdfs/
--------------------------------------------------------

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity onehot_to_binary_behave_16 is
port (
 onehot : in std_logic_vector(15 downto 0);
 binary : out std_logic_vector(3 downto 0));
end;

architecture hdfs of onehot_to_binary_behave_16 is
 -- .....some stuff cut out here

 -- declarations
 constant  hdfs_135 :  std_logic_vector(3 downto 0) := "1111";
 constant  hdfs_133 :  std_logic_vector(3 downto 0) := "1110";
 constant  hdfs_131 :  std_logic_vector(3 downto 0) := "1101";
 constant  hdfs_129 :  std_logic_vector(3 downto 0) := "1100";
 constant  hdfs_127 :  std_logic_vector(3 downto 0) := "1011";
 constant  hdfs_125 :  std_logic_vector(3 downto 0) := "1010";
 constant  hdfs_123 :  std_logic_vector(3 downto 0) := "1001";
 constant  hdfs_121 :  std_logic_vector(3 downto 0) := "1000";
 constant  hdfs_119 :  std_logic_vector(3 downto 0) := "0111";
 constant  hdfs_117 :  std_logic_vector(3 downto 0) := "0110";
 constant  hdfs_115 :  std_logic_vector(3 downto 0) := "0101";
 constant  hdfs_113 :  std_logic_vector(3 downto 0) := "0100";
 constant  hdfs_111 :  std_logic_vector(3 downto 0) := "0011";
 constant  hdfs_109 :  std_logic_vector(3 downto 0) := "0010";
 constant  hdfs_107 :  std_logic_vector(3 downto 0) := "0001";
 constant  hdfs_105 :  std_logic_vector(3 downto 0) := "0000";
 constant  hdfs_102 :  std_logic_vector(3 downto 0) := "0000";
 signal  hdfs_103 :  std_logic_vector(3 downto 0);
 signal  hdfs_136 :  std_logic_vector(3 downto 0);

begin

 -- logic
 process ( onehot ) is begin
  hdfs_136 <= hdfs_102;
  case onehot is
   when "0000000000000001" =>
    hdfs_136 <= hdfs_105;
   when "0000000000000010" =>
    hdfs_136 <= hdfs_107;
   when "0000000000000100" =>
    hdfs_136 <= hdfs_109;
   when "0000000000001000" =>
    hdfs_136 <= hdfs_111;
   when "0000000000010000" =>
    hdfs_136 <= hdfs_113;
   when "0000000000100000" =>
    hdfs_136 <= hdfs_115;
   when "0000000001000000" =>
    hdfs_136 <= hdfs_117;
   when "0000000010000000" =>
    hdfs_136 <= hdfs_119;
   when "0000000100000000" =>
    hdfs_136 <= hdfs_121;
   when "0000001000000000" =>
    hdfs_136 <= hdfs_123;
   when "0000010000000000" =>
    hdfs_136 <= hdfs_125;
   when "0000100000000000" =>
    hdfs_136 <= hdfs_127;
   when "0001000000000000" =>
    hdfs_136 <= hdfs_129;
   when "0010000000000000" =>
    hdfs_136 <= hdfs_131;
   when "0100000000000000" =>
    hdfs_136 <= hdfs_133;
   when "1000000000000000" =>
    hdfs_136 <= hdfs_135;
   when others => null;
  end case;
 end process;

 hdfs_103 <= hdfs_136;

 binary <= hdfs_103;

end architecture;

--------------------------------------------------------
-- Generated by HDFS version 0.2.1
-- http://code.google.com/p/hdfs/
--------------------------------------------------------

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity onehot_to_binary_struct_16 is
port (
 onehot : in std_logic_vector(15 downto 0);
 binary : out std_logic_vector(3 downto 0));
end;

architecture hdfs of onehot_to_binary_struct_16 is

 -- declarations
 constant  hdfs_110 :  std_logic_vector(3 downto 0) := "1111";
 constant  hdfs_111 :  std_logic_vector(3 downto 0) := "1110";
 constant  hdfs_116 :  std_logic_vector(3 downto 0) := "1101";
 constant  hdfs_117 :  std_logic_vector(3 downto 0) := "1100";
 constant  hdfs_126 :  std_logic_vector(3 downto 0) := "1011";
 constant  hdfs_127 :  std_logic_vector(3 downto 0) := "1010";
 constant  hdfs_132 :  std_logic_vector(3 downto 0) := "1001";
 constant  hdfs_133 :  std_logic_vector(3 downto 0) := "1000";
 constant  hdfs_146 :  std_logic_vector(3 downto 0) := "0111";
 constant  hdfs_147 :  std_logic_vector(3 downto 0) := "0110";
 constant  hdfs_152 :  std_logic_vector(3 downto 0) := "0101";
 constant  hdfs_153 :  std_logic_vector(3 downto 0) := "0100";
 constant  hdfs_162 :  std_logic_vector(3 downto 0) := "0011";
 constant  hdfs_163 :  std_logic_vector(3 downto 0) := "0010";
 constant  hdfs_168 :  std_logic_vector(3 downto 0) := "0001";
 constant  hdfs_169 :  std_logic_vector(3 downto 0) := "0000";
 signal  hdfs_112 :  std_logic_vector(3 downto 0);
 signal  hdfs_118 :  std_logic_vector(3 downto 0);
 signal  hdfs_120 :  std_logic_vector(3 downto 0);
 signal  hdfs_128 :  std_logic_vector(3 downto 0);
 signal  hdfs_134 :  std_logic_vector(3 downto 0);
 signal  hdfs_136 :  std_logic_vector(3 downto 0);
 signal  hdfs_138 :  std_logic_vector(3 downto 0);
 signal  hdfs_148 :  std_logic_vector(3 downto 0);
 signal  hdfs_154 :  std_logic_vector(3 downto 0);
 signal  hdfs_156 :  std_logic_vector(3 downto 0);
 signal  hdfs_164 :  std_logic_vector(3 downto 0);
 signal  hdfs_159 :  std_logic_vector(1 downto 0);
 signal  hdfs_166 :  std_logic;
 signal  hdfs_170 :  std_logic_vector(3 downto 0);
 signal  hdfs_161 :  std_logic;
 signal  hdfs_141 :  std_logic_vector(3 downto 0);
 signal  hdfs_158 :  std_logic_vector(1 downto 0);
 signal  hdfs_160 :  std_logic;
 signal  hdfs_165 :  std_logic;
 signal  hdfs_172 :  std_logic_vector(3 downto 0);
 signal  hdfs_151 :  std_logic;
 signal  hdfs_143 :  std_logic_vector(1 downto 0);
 signal  hdfs_150 :  std_logic;
 signal  hdfs_155 :  std_logic;
 signal  hdfs_145 :  std_logic;
 signal  hdfs_103 :  std_logic_vector(7 downto 0);
 signal  hdfs_140 :  std_logic_vector(3 downto 0);
 signal  hdfs_142 :  std_logic_vector(1 downto 0);
 signal  hdfs_144 :  std_logic;
 signal  hdfs_149 :  std_logic;
 signal  hdfs_157 :  std_logic;
 signal  hdfs_174 :  std_logic_vector(3 downto 0);
 signal  hdfs_131 :  std_logic;
 signal  hdfs_123 :  std_logic_vector(1 downto 0);
 signal  hdfs_130 :  std_logic;
 signal  hdfs_135 :  std_logic;
 signal  hdfs_125 :  std_logic;
 signal  hdfs_105 :  std_logic_vector(3 downto 0);
 signal  hdfs_122 :  std_logic_vector(1 downto 0);
 signal  hdfs_124 :  std_logic;
 signal  hdfs_129 :  std_logic;
 signal  hdfs_137 :  std_logic;
 signal  hdfs_115 :  std_logic;
 signal  hdfs_107 :  std_logic_vector(1 downto 0);
 signal  hdfs_114 :  std_logic;
 signal  hdfs_119 :  std_logic;
 signal  hdfs_109 :  std_logic;
 signal  hdfs_102 :  std_logic_vector(7 downto 0);
 signal  hdfs_104 :  std_logic_vector(3 downto 0);
 signal  hdfs_106 :  std_logic_vector(1 downto 0);
 signal  hdfs_108 :  std_logic;
 signal  hdfs_113 :  std_logic;
 signal  hdfs_121 :  std_logic;
 signal  hdfs_139 :  std_logic;
 signal  hdfs_176 :  std_logic_vector(3 downto 0);

begin

 -- logic
 hdfs_112 <= hdfs_111 when hdfs_108 = '0' else hdfs_110;
 hdfs_118 <= hdfs_117 when hdfs_114 = '0' else hdfs_116;
 hdfs_120 <= hdfs_118 when hdfs_113 = '0' else hdfs_112;
 hdfs_128 <= hdfs_127 when hdfs_124 = '0' else hdfs_126;
 hdfs_134 <= hdfs_133 when hdfs_130 = '0' else hdfs_132;
 hdfs_136 <= hdfs_134 when hdfs_129 = '0' else hdfs_128;
 hdfs_138 <= hdfs_136 when hdfs_121 = '0' else hdfs_120;
 hdfs_148 <= hdfs_147 when hdfs_144 = '0' else hdfs_146;
 hdfs_154 <= hdfs_153 when hdfs_150 = '0' else hdfs_152;
 hdfs_156 <= hdfs_154 when hdfs_149 = '0' else hdfs_148;
 hdfs_164 <= hdfs_163 when hdfs_160 = '0' else hdfs_162;
 hdfs_159 <= hdfs_141(1 downto 0);
 hdfs_166 <= hdfs_159(1);
 hdfs_170 <= hdfs_169 when hdfs_166 = '0' else hdfs_168;
 hdfs_161 <= hdfs_158(0);
 hdfs_141 <= hdfs_103(3 downto 0);
 hdfs_158 <= hdfs_141(3 downto 2);
 hdfs_160 <= hdfs_158(1);
 hdfs_165 <= hdfs_sl( hdfs_uns(hdfs_160) or hdfs_uns(hdfs_161) );
 hdfs_172 <= hdfs_170 when hdfs_165 = '0' else hdfs_164;
 hdfs_151 <= hdfs_143(0);
 hdfs_143 <= hdfs_140(1 downto 0);
 hdfs_150 <= hdfs_143(1);
 hdfs_155 <= hdfs_sl( hdfs_uns(hdfs_150) or hdfs_uns(hdfs_151) );
 hdfs_145 <= hdfs_142(0);
 hdfs_103 <= onehot(7 downto 0);
 hdfs_140 <= hdfs_103(7 downto 4);
 hdfs_142 <= hdfs_140(3 downto 2);
 hdfs_144 <= hdfs_142(1);
 hdfs_149 <= hdfs_sl( hdfs_uns(hdfs_144) or hdfs_uns(hdfs_145) );
 hdfs_157 <= hdfs_sl( hdfs_uns(hdfs_149) or hdfs_uns(hdfs_155) );
 hdfs_174 <= hdfs_172 when hdfs_157 = '0' else hdfs_156;
 hdfs_131 <= hdfs_123(0);
 hdfs_123 <= hdfs_105(1 downto 0);
 hdfs_130 <= hdfs_123(1);
 hdfs_135 <= hdfs_sl( hdfs_uns(hdfs_130) or hdfs_uns(hdfs_131) );
 hdfs_125 <= hdfs_122(0);
 hdfs_105 <= hdfs_102(3 downto 0);
 hdfs_122 <= hdfs_105(3 downto 2);
 hdfs_124 <= hdfs_122(1);
 hdfs_129 <= hdfs_sl( hdfs_uns(hdfs_124) or hdfs_uns(hdfs_125) );
 hdfs_137 <= hdfs_sl( hdfs_uns(hdfs_129) or hdfs_uns(hdfs_135) );
 hdfs_115 <= hdfs_107(0);
 hdfs_107 <= hdfs_104(1 downto 0);
 hdfs_114 <= hdfs_107(1);
 hdfs_119 <= hdfs_sl( hdfs_uns(hdfs_114) or hdfs_uns(hdfs_115) );
 hdfs_109 <= hdfs_106(0);
 hdfs_102 <= onehot(15 downto 8);
 hdfs_104 <= hdfs_102(7 downto 4);
 hdfs_106 <= hdfs_104(3 downto 2);
 hdfs_108 <= hdfs_106(1);
 hdfs_113 <= hdfs_sl( hdfs_uns(hdfs_108) or hdfs_uns(hdfs_109) );
 hdfs_121 <= hdfs_sl( hdfs_uns(hdfs_113) or hdfs_uns(hdfs_119) );
 hdfs_139 <= hdfs_sl( hdfs_uns(hdfs_121) or hdfs_uns(hdfs_137) );
 hdfs_176 <= hdfs_174 when hdfs_139 = '0' else hdfs_138;

 binary <= hdfs_176;

end architecture;


Article: 125268
Subject: Re: mess around with supply voltage to cyclone III
From: "David Spencer" <davidmspencer@verizon.net>
Date: Thu, 18 Oct 2007 19:49:30 GMT
Links: << >>  << T >>  << A >>
> Hi,
>
> I have a Cyclone III FPGA. I have created a circuit on it whose
> performance I want to observe under the influence of supply voltage
> variations and glitches.
>
> I want to create intentional glitches of this cyclone iii development
> board. Any ideas?
>
> -PrincessGateArray.
>
What you are trying to do sounds like a very dangerous approach to design. 
Even if you manage to achieve 100% test coverage of your design during the 
glitches and supply variations (which will depend on the complexity of the 
design and how you're testing it), you will still only have tested one 
sample. Your time would be much better spent ensuring that you have a stable 
power supply all the time. 



Article: 125269
Subject: Re: VHDL trivia?
From: Duane Clark <junkmail@junkmail.com>
Date: Thu, 18 Oct 2007 20:21:25 GMT
Links: << >>  << T >>  << A >>
Philip Herzog wrote:
> Hi folks!
> 
> A bit of VHDL trivia.
> 
> What I want is the reverse of:
> 
> 
> one_hot_gen: for i in 0 to 15 generate
> begin
>     one_hot(i) <= '1' when CONV_INTEGER(address) = i else '0';
> end generate;

How about

    addr_p: process (one_hot)
    begin
       address <= (others => '0');
       for i in 1 to 15 loop
          if one_hot(i) = '1' then
             address <= to_unsigned(i, 4);
          end if;
       end loop;
    end process addr_p;

Article: 125270
Subject: Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 18 Oct 2007 20:54:45 -0000
Links: << >>  << T >>  << A >>
On 18 Okt., 21:01, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Antti wrote:
> > Ok, this time it looks like solved. feel sosososoo stuuupid.
> > of course the internal skew of clocks is important, so adding manually
> > a global clock buffer seem have cured that. still pending of longer
> > testing, but it looks like ok now.
>
> So you are saying that todays FPGA fabrics (which one again here ?)
> now have such routing delays, (and fast registers) that Tco is less
> than Troute, and can violate Tsu/Th ?
>
> Maybe a longer shifter literally takes more room, so statistically
> has more chance of long/short routes in the wrong combination  ?
>
> If you run post route sim, does that flag any issues
> - ideally it should, right :)
>
> -jg

debug on top 4 bits, shift register 64 or 28 bits
"near ideal" external clock and shift data 4mhz down to 500khz
ProAsic3 FPGA

empty FPGA no matter synthesis settings - works correctly
full FPGA, 64 bits never worked unless forced global net
28 bits worked one P&R pass, not repeatable

surprising was that pattern 1001 did change to 1011 when the
issue was dominant in both cases of 28 and 64 lenghts! ?
and it was the same all P&R runs, and always the same 1011
also when the other logic changed a little.

to be honest i did expect that something simple as plain shift
register
will work properly (no matter what), that is the synthesis and P&R
tools
make the timings so that there are no violations.

another thing, the actel FPGA is REALLY full, the utilization varied
between 81-99%
so i was positivly surprised that actel tools never had any issues
with the implementation
no matter how full the FPGA was. even in runs where only 3 cells was
free!

but nothing comes for free - the internal skew on non global net, was
a hard hit in terms
of wasted time.

as there is no other explanation as net skew, and forcing global
buffer fixed the issue i
assume that that was it.

the only simulations I did run i did run with xilinx ISIM on the
design used as starting point
for the actel port, and on the xilinx back-ported version. I was about
to try post sims on
with actel timings, but as usual modelsim didnt want to start so i did
not get that far.
actel tools did not give any timing red alerts or anything

Antti


Article: 125271
Subject: Re: VHDL trivia?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 18 Oct 2007 21:55:43 +0100
Links: << >>  << T >>  << A >>
On Thu, 18 Oct 2007 20:21:25 GMT, 
Duane Clark <junkmail@junkmail.com> wrote:

>> What I want is the reverse of:
>> one_hot_gen: [...]
>
>How about
>
>    addr_p: process (one_hot)
>    begin
>       address <= (others => '0');
>       for i in 1 to 15 loop
>          if one_hot(i) = '1' then
>             address <= to_unsigned(i, 4);
>          end if;
>       end loop;
>    end process addr_p;

That, and Dave's similar suggestion, have the
feature (drawback? benefit?) that each lower-priority
bit must check that all higher-priority bits are zero
before asserting its value on to the output.  This is
typically rather extravagant, and it's unnecessary if
you are confident that the one-hot code is indeed one-hot
(or, more likely, you don't care what happens if it isn't).

This form will give you much more compact hardware (just
a few OR gates) at the expense of being somewhat less 
clear.  And if there is more than one bit of the input
"one-hot" code set, it will generate a silly result.

  onehot_to_binary: process (onehot) is
    variable OH: std_logic_vector (one_hot'length-1 downto 0);
    variable result: unsigned(address'range);
  begin
    -- Paranoia: Normalize the onehot vector
    -- so that you don't care how the original
    -- was defined.  Leftmost bit is number N-1,
    -- rightmost bit is number 0.
    OH := onehot;
    -- start the OR-tree
    result := (others => '0');
    -- build the OR-tree
    for i in OH'range loop
      if OH(i) = '1' then
        result := result OR to_unsigned(i, result'length);
      end if;
    end loop;
    -- copy result to your output signal
    address <= result;
  end process;

Tada! optimally small hardware.

No, I don't like it either.  I like it better than 
obscure code-generator scripts, though :-)

By the way: something like
  assert (2 ** address'length) > onehot'length
    report "Address not big enough to fit onehot value"
    severity failure;
sounds good to me.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 125272
Subject: Re: VHDL trivia?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 18 Oct 2007 22:03:24 +0100
Links: << >>  << T >>  << A >>
On Thu, 18 Oct 2007 15:04:24 +0200, 
Philip Herzog <phq@arcor.de> wrote:

>What I want is the reverse of:
>
>one_hot_gen: for i in 0 to 15 generate
>begin
>    one_hot(i) <= '1' when CONV_INTEGER(address) = i else '0';
>end generate;

See my response to Duane Clark, later in the thread, for a 
direct answer.

HOWEVER... two fairly serious nitpicks with your decoder
design.

1) Break the bad habit of using nasty obsolete flaky 
arithmetic packages, and switch to NUMERIC_STD.  Then
your CONV_INTEGER function (to integer? from integer)
becomes TO_INTEGER, and correctly requires "address"
to be UNSIGNED.

2) The generate loop is unnecessarily obscure, and will
simulate more slowly than is necessary.  Instead, consider
a procedural loop:

  -- assumes Address is declared "unsigned"
  process (address)
  begin
    one_hot <= (others => '0');
    for i in one_hot'range loop
      if address = i then
        one_hot(i) <= '1';
      end if;
    end loop;
  end process;

(Note that it's OK to compare an UNSIGNED address with an
integer, without conversions.)

Or, even better:

  process(address)
  begin
    one_hot <= (others => '0');
    one_hot(to_integer(address)) <= '1';
  end process;
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 125273
Subject: Re: VHDL trivia?
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 18 Oct 2007 17:28:15 -0400
Links: << >>  << T >>  << A >>

"Philip Herzog" <phq@arcor.de> wrote in message 
news:471759D8.1020700@arcor.de...
> Hi folks!
>
> A bit of VHDL trivia.
>
> What I want is the reverse of:
>
>
> one_hot_gen: for i in 0 to 15 generate
> begin
>    one_hot(i) <= '1' when CONV_INTEGER(address) = i else '0';
> end generate;
>
<snip>
> Any ideas?
>

The short answer is shown in the VHDL functions below (for an 8 state one 
hot encoding).  Left as an exercise is extension to other bit widths. 
You'll find that this structure will most likely always result in the 
minimal synthesized logic representation.

function Encode_OneHots(L: std_ulogic_vector) return std_ulogic_vector is
 variable RetVal: std_ulogic_vector(2 downto 0);
begin
 RetVal(0) := L(1) xor L(3) xor L(5) xor L(7);
 RetVal(1) := L(2) xor L(3) xor L(6) xor L(7);
 RetVal(2) := L(4) xor L(5) xor L(6) xor L(7);

 RetVal(0) := L(1) or L(3) or L(5) or L(7);
 RetVal(1) := L(2) or L(3) or L(6) or L(7);
 RetVal(2) := L(4) or L(5) or L(6) or L(7);

 return(RetVal);
end function Encode_OneHots;

function Decode_OneHots(L: std_ulogic_vector) return std_ulogic_vector is
 variable RetVal: std_ulogic_vector(7 downto 0);
begin
 RetVal := (others => '0');
 RetVal(to_integer(unsigned(L))) := '1';
 return(RetVal);

The somewhat longer answer is that darn near every time people talk about 
one-hot encoding it is usually in the context of state machines or 
enumerated types.  In that scenario, one can convert enumerations to/from 
vectors with the functions shown below.  When used in pairs in the correct 
fashion, the pair results in 0 logic gates synthesized.

type My_Type is (s0, s1, s2, s3, s4, s5, s6, s7);

function To_Std_ULogic_Vector(L: My_Type) return std_ulogic_vector is
 variable RetVal: std_ulogic_vector(2 downto 0); -- '2' should be 
log2(My_Type'length) - 1
begin
 RetVal := std_ulogic_vector(to_unsigned(My_Type'pos(L), RetVal'length));
 return(RetVal);
end function To_Std_ULogic_Vector;

function From_Std_ULogic_Vector(L: std_ulogic_vector) return My_Type is
 variable RetVal: My_Type;
begin
 RetVal := My_Type'val(to_integer(unsigned(L)));
 return(RetVal);
end function From_Std_ULogic_Vector;

For an even deeper understanding of the problem about why working directly 
with one hots and reversing the decoding is probably not the best approach 
in the first place, read the side discussion on exactly this topic that 
starts at link below.  That thread will also get into showing why any 
solution that involves if/elsif/end if; or a case statement will result in a 
lot of extra logic being generated (as Andy seems to have rediscovered on 
his last post to your thread).

http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/77ea136174190b69/0fa19ddd6dbb2fec?lnk=gst&q=orif+KJ#0fa19ddd6dbb2fec

That whole thread is quite long, posts #81-90 cover the gist of what you're 
asking about (the link above is to #81).  90-100 or so go off on another 
tangent and there are even more tangents in there as well.

KJ



Article: 125274
Subject: Re: What to consider for source synchronous clocking?
From: Gabor <gabor@alacron.com>
Date: Thu, 18 Oct 2007 14:54:49 -0700
Links: << >>  << T >>  << A >>
On Oct 18, 11:26 am, "David Spencer" <davidmspen...@verizon.net>
wrote:
> > I'm using a Spartan 3 right now, and I'm trying to provide source
> > synchronous clock clocking to a SDR SDRAM using DDR register.
> > The component looks something like this:
>
> I'm not sure if it's possible in your design, but by far the simplest
> solution would be to use a single external clock that drives both the SDRAM
> and all your FPGA logic (through a clock buffer if necessary). If you must
> derive the SDRAM clock from the FPGA then one thing you can do is drive out
> the derived clock from an I/O and feed it to both the SDRAM and loopback to
> an FPGA clock pin (again using a buffer if needed). Both of these approaches
> avoid having to worry about IOB delays in the clock output.


I missed the "SDR" bit when I replied earlier.  I agree that a radial
clock distribution is easiest for single-data-rate parts.  Also forget
the bit about duty cycle, these aren't as picky as DDR parts, which
use
both edges.

I've made source-synchronous SDR SDRAM systems using a global clock
pin as an I/O (not available in all FPGA series) and pin feedback for
the internal clock.  Otherwise you may need to use a wire for
feedback.
I wouldn't worry about length matching, especially if your part has
DCM's for phase-shifting the internal clock (and Spartan 3 does).  But
this means that the clock you supply to the DDR output flop is not
the same one used internally for the rest of your logic.




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