Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
> 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
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
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: 125253Metastability 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
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, EricArticle: 125255
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
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
"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
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
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
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
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
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
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, PatrickArticle: 125264
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. AndyArticle: 125265
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 ? :) -jgArticle: 125266
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 :) -jgArticle: 125267
>
> 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> 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
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: 125270On 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 AnttiArticle: 125271
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
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"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. KJArticle: 125274
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:
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