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
On Jul 15, 6:30=A0pm, "MM" <mb...@yahoo.com> wrote: > "Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote > > > > > it sounds as though you're some kind of manager :-) > > More like a student who doesn't have a clue... may be a student who's been given a H.W , but then you need to know how to make and, or, not... gates in FPGA, and study more before you start to think on implementing parallel image processing algorithms!! > > /MikhailArticle: 141901
Hi there,
I used Xilinx Architecture wizard to generate the code and the clock
multiplication works correctly in timing simulation. Synthesis works
too.
I've an input 50MHz oscillator clock and I need following clock
signals :
- 50MHz clock (ADCs ENC+ pin)
- 50MHz 180 deg phase shifted (ADCs ENC- pin)
- 200MHz for system clock
- 40MHz clock (Oser Serial ADC CLK)
I used 2 DCM in serie to provide(CoreGen provides this IP) :
-50MHz x 4 = 200MHz (linked the 2x first DCM output to the CK input of
the 2nd DCM)
-I used the CLK0 for 50MHz
- CLK180 for 50MHz 180 deg shifted signal
An other DCM divides the 200MHz clock by five to get the 40MHz clock.
The problem occurs when I connect this block with the DCMs VHD file
(named CLOCK_GENERATOR) with the rest of the design. Even if I
understand following errors, I don't know how to correct them! I tried
some stuff but it didn't worked:/
ERROR:NgdBuild:770 - IBUFG 'CLK/CK40MHZ/CLKIN_IBUFG_INST' and BUFG
'CLK/CLK200MHZ/U2_CLK2X_BUFG_INST' on net
'GCLK_OBUF' are lined up in series. Buffers of the same direction
cannot be placed in series.
ERROR:NgdBuild:462 - input pad net 'GCLK_OBUF' drives multiple
buffers:
pin I on block CLK/CK40MHZ/CLKIN_IBUFG_INST with type IBUFG, pin I
on block GCLK_OBUF with type OBUF
ERROR:NgdBuild:924 - input pad net 'GCLK_OBUF' is driving non-buffer
primitives:
pin C on block ADC_INT/EDGE_BUFF_40MHz_0 with type FDC,
pin C on block ADC_INT/SCLK_EDGE_BUFF_0 with type FDC,
pin C on block ADC_INT/ADC_SDATA_LATCH with type FDC,
pin C on block ADC_INT/EDGE_BUFF_40MHz_1 with type FDC,
pin C on block ADC_INT/SCLK_EDGE_BUFF_1 with type FDC,
pin C on block ADC_INT/INIT_CPT_0 with type FDCE,
pin C on block ADC_INT/INIT_CPT_1 with type FDCE,
pin C on block ADC_INT/INIT_CPT_2 with type FDCE,
pin C on block ADC_INT/INIT_CPT_3 with type FDCE,
pin C on block ADC_INT/INIT_CPT_4 with type FDCE,
pin C on block ADC_INT/INIT_CPT_5 with type FDCE,
pin C on block ADC_INT/INIT_CPT_6 with type FDCE,
pin C on block ADC_INT/INIT_CPT_7 with type FDCE,
pin C on block ADC_INT/INIT_CPT_8 with type FDCE,
pin C on block ADC_INT/INIT_CPT_9 with type FDCE,
pin C on block ADC_INT/EP_FSM_FFd3 with type FDC,
pin C on block ADC_INT/EP_FSM_FFd1 with type FDC,
pin C on block ADC_INT/EP_FSM_FFd2 with type FDC,
pin C on block ADC_COS/LATCHED_DATA_0 with type FDCE_1,
pin C on block ADC_COS/LATCHED_DATA_1 with type FDCE_1
ERROR:NgdBuild:947 - input pad net 'GCLK_OBUF' is driving non-input
buffer(s):
pin C on block ADC_INT/EDGE_BUFF_40MHz_0 with type FDC,
pin C on block ADC_INT/SCLK_EDGE_BUFF_0 with type FDC,
pin C on block ADC_INT/ADC_SDATA_LATCH with type FDC,
pin C on block ADC_INT/EDGE_BUFF_40MHz_1 with type FDC,
pin C on block ADC_INT/SCLK_EDGE_BUFF_1 with type FDC,
pin C on block ADC_INT/INIT_CPT_0 with type FDCE,
pin C on block ADC_INT/INIT_CPT_1 with type FDCE,
pin C on block ADC_INT/INIT_CPT_2 with type FDCE,
pin C on block ADC_INT/INIT_CPT_3 with type FDCE,
pin C on block ADC_INT/INIT_CPT_4 with type FDCE,
pin C on block ADC_INT/INIT_CPT_5 with type FDCE,
pin C on block ADC_INT/INIT_CPT_6 with type FDCE,
Here are DCM VHD files :
entity GCLK is
port ( U1_CLKIN_IN : in std_logic;
U1_RST_IN : in std_logic;
CLK180_OUT : out std_logic;
U1_CLKIN_IBUFG_OUT : out std_logic;
U1_CLK2X_OUT : out std_logic;
U1_STATUS_OUT : out std_logic_vector (7 downto 0);
U2_CLK0_OUT : out std_logic;
U2_CLK2X_OUT : out std_logic;
U2_LOCKED_OUT : out std_logic;
U2_STATUS_OUT : out std_logic_vector (7 downto 0));
end GCLK;
-- 2 DCM in serial
architecture BEHAVIORAL of GCLK is
signal GND_BIT : std_logic;
signal U1_CLKIN_IBUFG : std_logic;
signal U1_CLK2X_BUF : std_logic;
signal U1_CLK180_BUF : std_logic;
signal U1_LOCKED_INV_IN : std_logic;
signal U2_CLKFB_IN : std_logic;
signal U2_CLKIN_IN : std_logic;
signal U2_CLK0_BUF : std_logic;
signal U2_CLK2X_BUF : std_logic;
signal U2_FDS_Q_OUT : std_logic;
signal U2_FD1_Q_OUT : std_logic;
signal U2_FD2_Q_OUT : std_logic;
signal U2_FD3_Q_OUT : std_logic;
signal U2_LOCKED_INV_RST : std_logic;
signal U2_OR3_O_OUT : std_logic;
signal U2_RST_IN : std_logic;
begin
GND_BIT <= '0';
U1_CLKIN_IBUFG_OUT <= U1_CLKIN_IBUFG;
U1_CLK2X_OUT <= U2_CLKIN_IN;
U2_CLK0_OUT <= U2_CLKFB_IN;
DCM_SP_INST1 : DCM_SP
generic map( CLK_FEEDBACK => "2X",
CLKDV_DIVIDE => 1.5,
CLKFX_DIVIDE => 1,
CLKFX_MULTIPLY => 4,
CLKIN_DIVIDE_BY_2 => FALSE,
CLKIN_PERIOD => 20.000,
CLKOUT_PHASE_SHIFT => "NONE",
DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",
DFS_FREQUENCY_MODE => "LOW",
DLL_FREQUENCY_MODE => "LOW",
DUTY_CYCLE_CORRECTION => TRUE,
FACTORY_JF => x"C080",
PHASE_SHIFT => 0,
STARTUP_WAIT => FALSE)
port map (CLKFB=>U2_CLKIN_IN,
CLKIN=>U1_CLKIN_IBUFG,
DSSEN=>GND_BIT,
PSCLK=>GND_BIT,
PSEN=>GND_BIT,
PSINCDEC=>GND_BIT,
RST=>U1_RST_IN,
CLKDV=>open,
CLKFX=>open,
CLKFX180=>open,
CLK0=>open,
CLK2X=>U1_CLK2X_BUF,
CLK2X180=>open,
CLK90=>open,
CLK180=>U1_CLK180_BUF,
CLK270=>open,
LOCKED=>U1_LOCKED_INV_IN,
PSDONE=>open,
STATUS(7 downto 0)=>U1_STATUS_OUT(7 downto 0));
DCM_SP_INST2 : DCM_SP
generic map( CLK_FEEDBACK => "1X",
CLKDV_DIVIDE => 2.0,
CLKFX_DIVIDE => 1,
CLKFX_MULTIPLY => 4,
CLKIN_DIVIDE_BY_2 => FALSE,
CLKIN_PERIOD => 10.000,
CLKOUT_PHASE_SHIFT => "NONE",
DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",
DFS_FREQUENCY_MODE => "LOW",
DLL_FREQUENCY_MODE => "LOW",
DUTY_CYCLE_CORRECTION => TRUE,
FACTORY_JF => x"C080",
PHASE_SHIFT => 0,
STARTUP_WAIT => FALSE)
port map (CLKFB=>U2_CLKFB_IN,
CLKIN=>U2_CLKIN_IN,
DSSEN=>GND_BIT,
PSCLK=>GND_BIT,
PSEN=>GND_BIT,
PSINCDEC=>GND_BIT,
RST=>U2_RST_IN,
CLKDV=>open,
CLKFX=>open,
CLKFX180=>open,
CLK0=>U2_CLK0_BUF,
CLK2X=>U2_CLK2X_BUF,
CLK2X180=>open,
CLK90=>open,
CLK180=>open,
CLK270=>open,
LOCKED=>U2_LOCKED_OUT,
PSDONE=>open,
STATUS(7 downto 0)=>U2_STATUS_OUT(7 downto 0));
U1_CLKIN_IBUFG_INST : IBUFG
port map (I=>U1_CLKIN_IN,
O=>U1_CLKIN_IBUFG);
U1_CLK2X_BUFG_INST : BUFG
port map (I=>U1_CLK2X_BUF,
O=>U2_CLKIN_IN);
U1_CLK180_BUFG_INST : BUFG
port map (I=>U1_CLK180_BUF,
O=>CLK180_OUT);
U1_INV_INST : INV
port map (I=>U1_LOCKED_INV_IN,
O=>U2_LOCKED_INV_RST);
U2_CLK0_BUFG_INST : BUFG
port map (I=>U2_CLK0_BUF,
O=>U2_CLKFB_IN);
U2_CLK2X_BUFG_INST : BUFG
port map (I=>U2_CLK2X_BUF,
O=>U2_CLK2X_OUT);
U2_FDS_INST : FDS
port map (C=>U2_CLKIN_IN,
D=>GND_BIT,
S=>GND_BIT,
Q=>U2_FDS_Q_OUT);
U2_FD1_INST : FD
port map (C=>U2_CLKIN_IN,
D=>U2_FDS_Q_OUT,
Q=>U2_FD1_Q_OUT);
U2_FD2_INST : FD
port map (C=>U2_CLKIN_IN,
D=>U2_FD1_Q_OUT,
Q=>U2_FD2_Q_OUT);
U2_FD3_INST : FD
port map (C=>U2_CLKIN_IN,
D=>U2_FD2_Q_OUT,
Q=>U2_FD3_Q_OUT);
U2_OR2_INST : OR2
port map (I0=>U2_LOCKED_INV_RST,
I1=>U2_OR3_O_OUT,
O=>U2_RST_IN);
U2_OR3_INST : OR3
port map (I0=>U2_FD3_Q_OUT,
I1=>U2_FD2_Q_OUT,
I2=>U2_FD1_Q_OUT,
O=>U2_OR3_O_OUT);
end BEHAVIORAL;
-- signle DCM
entity CLK40MHZ is
port ( CLKIN_IN : in std_logic;
RST_IN : in std_logic;
CLKDV_OUT : out std_logic;
CLKIN_IBUFG_OUT : out std_logic;
CLK0_OUT : out std_logic;
LOCKED_OUT : out std_logic);
end CLK40MHZ;
architecture BEHAVIORAL of CLK40MHZ is
signal CLKFB_IN : std_logic;
signal CLKIN_IBUFG : std_logic;
signal CLK0_BUF : std_logic;
signal GND_BIT : std_logic;
begin
GND_BIT <= '0';
CLKIN_IBUFG_OUT <= CLKIN_IBUFG;
CLK0_OUT <= CLKFB_IN;
CLKIN_IBUFG_INST : IBUFG
port map (I=>CLKIN_IN,
O=>CLKIN_IBUFG);
CLK0_BUFG_INST : BUFG
port map (I=>CLK0_BUF,
O=>CLKFB_IN);
DCM_SP_INST : DCM_SP
generic map( CLK_FEEDBACK => "1X",
CLKDV_DIVIDE => 2.5,
CLKFX_DIVIDE => 1,
CLKFX_MULTIPLY => 4,
CLKIN_DIVIDE_BY_2 => TRUE,
CLKIN_PERIOD => 10.000,
CLKOUT_PHASE_SHIFT => "NONE",
DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",
DFS_FREQUENCY_MODE => "LOW",
DLL_FREQUENCY_MODE => "LOW",
DUTY_CYCLE_CORRECTION => TRUE,
FACTORY_JF => x"C080",
PHASE_SHIFT => 0,
STARTUP_WAIT => FALSE)
port map (CLKFB=>CLKFB_IN,
CLKIN=>CLKIN_IBUFG,
DSSEN=>GND_BIT,
PSCLK=>GND_BIT,
PSEN=>GND_BIT,
PSINCDEC=>GND_BIT,
RST=>RST_IN,
CLKDV=>CLKDV_OUT,
CLKFX=>open,
CLKFX180=>open,
CLK0=>CLK0_BUF,
CLK2X=>open,
CLK2X180=>open,
CLK90=>open,
CLK180=>open,
CLK270=>open,
LOCKED=>LOCKED_OUT,
PSDONE=>open,
STATUS=>open);
end BEHAVIORAL;
Article: 141902I'm having the same issue right now with the Marvell 78200 CPU. Going to use the Device Bus to configure the FPGA via SelectMAP. >rickman <gnuarm@gmail.com> wrote in >news:9e5e3729-4da1-41b4-9ec2-9c8f5dfe24d6@r36g2000vbp.googlegroups.com: > >> On Feb 25, 4:49 am, Allan Herriman <allanherri...@hotmail.com> wrote: >>> rickman <gnu...@gmail.com> wrote >>> innews:3774b465-11f4-4daa-aee7-d44f72fce9a6@n20g2000vba.googlegroups.c >>> om: >>> >>> >>> >>> > On Feb 24, 8:27 am, Allan Herriman <allanherri...@hotmail.com> >>> > wrote: >>> >> "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote >>> >> innews:go0pr0$6jj$1@ai >>> > oe.org: >>> >>> >> > "Allan Herriman" <allanherri...@hotmail.com> wrote in message >>> >> >news:Xns9BBCD0C44FABBallanherrimanhotmail@216.151.153.43... >>> >> >> Hi, >>> >>> >> >> I guess my questions are: >>> >>> >> >> 2. Will future generations FPGAs be able to be programmed via >>> >> >> PCIe? If so, when? >>> >>> >> > Now? ;) Just need to use some external components to tie it >>> >> > together...or use partial reconfiguration (PR) flow. >>> >>> >> I meant "gluelessly". With PR, one must get the original >>> >> configuration into the FPGA somehow, and (as I understand it) that >>> >> cannot be done with PCIe. >>> >>> >> Thanks for your comments. >>> >>> >> Allan >>> >>> > I haven't looked at processors like the Atom in a while, but I seem >>> > to recall that you get some number of general purpose I/O pins on >>> > most any processor. You only need four pins to completely control >>> > an FPGA configuration; PRGM, CCLK, DONE, INIT. They can be bit >>> > banged in software. The FPGA interface is not used very much when >>> > considered in the grand scheme of things. So I expect you will >>> > never see direct support for it on processors. >>> >>> > I also doubt that you will see dedicated support for PCIe in FPGAs. >>> > This is a bit lofty for a configuration interface. PCIe is point >>> > to point (right?) and taking one of the two PCIe interfaces on an >>> > Atom for booting the FPGA would be a bit of overkill. There are >>> > few applications where a processor like the Atom is used and you >>> > can't wait the few milliseconds for the FPGA to boot serially. >>> >>> That PCIe isn't wasted; it is needed for FPGA <-> cpu comms after >>> configuration. >> >> In your case that may be useful. My point is that in the general case >> this is not something that would be widely useful since PCIe ports are >> a very "expensive" way to configure a part when all you really need is >> four GPIO pins on the host. >> >> >>> I was actually thinking of applications without the chance of using >>> GPIO lines, e.g. on a PCIe plugin card. >> >> I don't know PCIe much, but I have worked with PCI before and I don't >> think it is practical to use an FPGA to provide the PCI interface. >> This issue may have been resolved at some point, but I want to say >> that an FPGA does not boot fast enough to respond to the initial >> enumeration comms on the bus. Has this issue been addressed so that >> an FPGA can boot from an on board PROM and provide a PCIe interface? >> >> >>> It still seems that the PCIe to local bus bridge is the best solution >>> for my hypothetical problem. The other suggestions involved Flash >>> memories (with an implied extra step during manufacturing to program >>> the dang things, not to mention the extra complexity involved with >>> in-the-field upgrades of that image) or a non-trivial amount of glue >>> logic. >> >> I think the idea is that the image required to boot the FPGA enough to >> make it bootable over the PCIe interface would be pretty stable. So >> the concerns of needing to fix that would be a bit overblown. In >> fact, it is likely that you could design the interface to the boot >> Flash so that it can be programmed over the PCIe bus. Then, as long >> as the reprogramming did not go bust in the middle, you could update >> the Flash just like you load the rest of the image. >> >> Of course, the local bus interface still requires some extra logic to >> boot the FPGA, no? Or does the bridge chip provide signals that can >> be used directly? > > >They usually have a few GPIO lines as well as a parallel data bus. This >allows some sort of slave parallel mode to be used without glue logic. > >Just in case you are interested, here are some typical parts: > >1 Lane: >http://www.plxtech.com/products/expresslane/pex8311.asp > >4 Lanes with dedicated FPGA loading support: >http://www.gennum.com/video/products/gn4124 > >Here's the article that inspired this thread: >http://www.pldesignline.com/howto/210300269 > >Regards, >Allan >Article: 141903
Nauman Mir <mir6@hotmail.com> writes: > hi Good Day! > I hope you all are fine. Actually i want to take some technical > input. I want to build 10,000 floating point multiplier in FPGA > fabric. So > That's a lot of multipliers! Unfortunately I have only more questions for you: What are you doing that needs this qty of multipliers? Do you really need floating point? What word size? What data rate? > > Kindly suggest me Is it possible ? Not taking your query at face value - a single-precision FP multiplier from Xilinx Coregen runs to 1000 or so LUTs (IIRC), so that's a 10MLUT FPGA... (actually, DSP blocks would probably be the limiting factor anyway, but it's still infeasible!). The largest Virtex 6 looks like about 450k LUTs... Now, if you actually need to do 10,000 multiplies one after the other, that's very different story... > > How we can implement ? (my suggestion is MicroBlaze soft processor) Only if you want the answer realtively slowly, in which case a normal processor rather than an FPGA would better suit the problem. That would also be a sequential solution. > > Which Chip_Set is best for this purpose ? > Insufficient data. sorry! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 141904
On Wed, 15 Jul 2009 09:19:36 -0700, Peter Alfke wrote: > On Jul 15, 7:11Â am, Allan Herriman <allanherri...@hotmail.com> wrote: >> >> Before I forgot, anyone contemplating using a block ram as a rom should >> read this Xilinx Answer Record which describes a way that the rom >> contents can be corrupted: >> >> http://www.xilinx.com/support/answers/21870.htm >> >> Regards, >> Allan > > Thank you, Allan, for pointing this out (it is also documented in the > User Guide). The problem is caused by metastability in the address > register, fouling up the address decoder. The easy cure is to disable > the clock whenever the address inputs are asynchronous. > This should not be of concern to any FSM design, since its control > inputs should be pre-synchronized under all circumstances. Peter Alfke Thanks Peter. You might recall that the problem I had with a Virtex2Pro Block RAM was caused by glitches on the clock coming from the DCM during initial lock. My design was completely synchronous and passed STA. From that, I conclude that synchronising all inputs to the clock is not sufficient to stop the corruption, if the design uses a DCM. I did find (empirically) that disabling the clock with a BUFGMUX during the initial lock period was sufficient to fix the problem. Disabling the RAM by negating its CE input would also work, and this is the method recommended in the answer record. Regards, AllanArticle: 141905
On Wed, 15 Jul 2009 09:08:58 +0100, Jonathan Bromley wrote: >>I know how to do it in 9 LUTs. >Whoops, I can't count. That should be 3+2+2+1+1+1+1 = 11. >Don't know where I got 9 from, sorry. And 11 it is, in a Spartan-3 at any rate. A day late, sorry. Real work got in the way :-) I've done my best, but I cannot get this from synthesis. The tools always rework the narrow adders as a bunch of LUTs without using the carry chains, and I get at least 17 or 18 LUTs. But the 11-LUT schematic is here: http://www.oxfordbromley.plus.com/files/minimal_bitcounter.pdf Although it's only 11 LUTs, it occupies 8 slices because of the carry chains. All the LUTs are simple XOR gates (INIT=6, I think?) as usual in an ordinary adder. It's just an adder tree, somewhat along the lines of the carry save adder described by Glen earlier. -- 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: 141906
On Jul 16, 4:34=A0am, Rmorzelle <rmorze...@netcourrier.com> wrote: > Hi there, > > I used Xilinx Architecture wizard to generate the code and the clock > multiplication works correctly in timing simulation. Synthesis works > too. -snip- Why? A single DCM with a 50 MHz input can be used to provide: 50 MHz from CLK0 50 MHz 180 degrees from CLK180 100 MHz from CLK2X 200 MHz from CLKFX using M=3D2, D=3D1, ... Then use another DCM driven from the same CLKIN as the first DCM to provide 40 MHz by using CLKFX, M=3D4, D=3D5 (50 *4/5=3D 40). Do not place DCMs in series (if at all possible). You can use more than one output from a DCM at once. Proper choice of Fin would probably allow you to get all your outputs from just one DCM. I can't help you with your coding (sorry, I'm just as likely aas you to make errors there, and not see them), AustinArticle: 141907
MM wrote: >> I'm using a module written by the vendor of the boards that mounts the >> FPGA. > 1. Why don't you use Xilinx core? It will work happily with a single clock. > 2. If you really need to invert a DCM CLKDIV clock it you can use a second > DCM. I interfaced my DSP code with base code of the board (an ADC board). I don't want to modify the original code. I think they didn't use the Xilinx core because the fifo's depth is about 12000, Xilinx core accept only power of 2 depths if I remember well. > Also, take a look at the PMCD (Phase-Matched Clock Divider) V4 primitive. I will, thanks. -- I may not have gone where I intended to go, but I think I have ended up where I needed to be. _ _ _ | \| |___ _ __ ___ __(_)___ | .` / -_) ' \/ -_|_-< (_-< |_|\_\___|_|_|_\___/__/_/__/ http://xpn.altervista.orgArticle: 141908
On Jul 16, 11:41=A0am, Nemesis <neme...@nowhere.invalid> wrote: > MM wrote: > >> I'm using a module written by the vendor of the boards that mounts the > >> FPGA. > > 1. Why don't you use Xilinx core? It will work happily with a single cl= ock. > > 2. If you really need to invert a DCM CLKDIV clock it you can use a sec= ond > > DCM. > > I interfaced my DSP code with base code of the board (an ADC board). > I don't want to modify the original code. I think they didn't use the > Xilinx core because the fifo's depth is about 12000, Xilinx core accept > only power of 2 depths if I remember well. > I have never seen an application where the exact FIFO depth value was critical, as long as it was deep enough. Also, there is the ALMOST FULL flag that can be set to any value. Peter Alfke, XilinxArticle: 141909
On Jul 16, 2:48=A0pm, Peter Alfke <pe...@xilinx.com> wrote: > On Jul 16, 11:41=A0am, Nemesis <neme...@nowhere.invalid> wrote:> MM wrote= : > > >> I'm using a module written by the vendor of the boards that mounts t= he > > >> FPGA. > > > 1. Why don't you use Xilinx core? It will work happily with a single = clock. > > > 2. If you really need to invert a DCM CLKDIV clock it you can use a s= econd > > > DCM. > > > I interfaced my DSP code with base code of the board (an ADC board). > > I don't want to modify the original code. I think they didn't use the > > Xilinx core because the fifo's depth is about 12000, Xilinx core accept > > only power of 2 depths if I remember well. > > I have never seen an application where the exact FIFO depth value was > critical, as long as it was deep enough. > Also, there is the ALMOST FULL flag that can be set to any value. > Peter Alfke, Xilinx The point is that deep enough is often not a power of two and you may not have the block RAM to waste on the unused portion. The control circuitry would obviously be the same size since you haven't reduced the number of address bits.Article: 141910
I was reading in Ben Cohen's book that OPEN has some restrictions. One is that it can not be used with a specified set of items in an array when the other items are mapped to other signals. Here is an example. Mul: multiply PORT MAP ( SysClk => SysClk, -- System clock, 12.288 MHz? Start => Start, -- Load multiplican and init result Multiplicand => LinDat, Multiplier => std_logic_vector(AudioGain), Product(ProdHigh downto ProdHigh - MulOut'high) => MulOut, Product(ProdHigh - MulOut'high - 1 downto 0) => OPEN, Done => Done ); According to Ben Cohen book, the product can not be split this way using OPEN. When I tried it with Synplicity it seems to accept this syntax. Ben's book is a bit older and refers to the '93 standard. I believe there is a newer VHDL standard, 200x. Is this something that has changed since '93 or is the Synplicity tool just being magnanimous? Should I change it so that it will work with other tools or do most tools accept this? Rick PS Don't ask me the name of the book, I don't have it with me. It was a larger book and consisted of many examples of specific aspects of the language rather than a general explanation of the language. I like paper books, but sometimes I like the portability of e-books (pdf).Article: 141911
I find there are any number of aspects of the VHDL language that I just do not remember and I am not going to make up flash cards to help me remember. So I drag a half dozen VHDL books around with me when I am working on VHDL (or much less frequently, Verilog; one of the books covers both). I am getting tired of heaving the books up into the truck every time I go to the lake and am starting to wonder if I should invest in some good e-books on HDL. What do the rest of you prefer? Do you have both? Do you still need to rely on your books or do you pretty well have the language down pat? Is the IEEE VHDL standard available in e-book format? Maybe I need to invest in the 200x version anyway? RickArticle: 141912
In article <f1054448-63ea-465b-af39-a6c9c44f0ca1@32g2000yqj.googlegroups.com>, Peter Alfke <peter@xilinx.com> writes: >Thank you, Allan, for pointing this out (it is also documented in the >User Guide). The problem is caused by metastability in the address >register, fouling up the address decoder. >The easy cure is to disable the clock whenever the address inputs are >asynchronous. Could you please say a bit more? How does data get corrupted when write-enable is off? I can understand a write going to the wrong place(s) if the address doesn't meet setup, but I don't see how metastability on the addresses can write somewhere when write-enable is off. I guess the actual implementation doesn't translate into normal logic where an off signal on write-enable would block the update signal even if wome other input to the gate was garbage. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 141913
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote: (snip) < Could you please say a bit more? How does data get corrupted when < write-enable is off? < I can understand a write going to the wrong place(s) if the address < doesn't meet setup, but I don't see how metastability on the < addresses can write somewhere when write-enable is off. I suppose it makes some sense. The address decoders go to enable lines that enable the signal coming out of the bit cells onto the sense lines. If, for example, two enable lines were active at once then two cells would be enabled onto the same sense line. If the address goes metastable, it seems that could happen. Presumably this is true for non-FPGA RAMs, too. < I guess the actual implementation doesn't translate into normal logic < where an off signal on write-enable would block the update < signal even if wome other input to the gate was garbage. -- glenArticle: 141914
On Thu, 16 Jul 2009 16:24:19 -0700 (PDT), rickman <gnuarm@gmail.com> wrote: >I find there are any number of aspects of the VHDL language that I >just do not remember and I am not going to make up flash cards to help >me remember. So I drag a half dozen VHDL books around with me when I >am working on VHDL (or much less frequently, Verilog; one of the books >covers both). > >I am getting tired of heaving the books up into the truck every time I >go to the lake and am starting to wonder if I should invest in some >good e-books on HDL. > >What do the rest of you prefer? Do you have both? Do you still need >to rely on your books or do you pretty well have the language down >pat? PDF, by far, when I can find a good one, and for all tech topics & datasheets, not just VHDL. The search capability alone is worth the relative pain of having to boot the PC. If I'll also be using the PC in the project (nearly certain) then the cost falls to zero. While it's on your radar, if you do go paperless and don't stay with a standard format like PDF (e.g., Kindle) make damn sure that you read the terms and conditions. I don't have the citation (it's probably on El Reg) but I did read about one gent who pissed off Amazon with too many returns and they cancelled his account. As a side effect, that locked him out of the Kindle volumes he had already purchased. Ugh. <clickety click> Nope, it was over at Ars Technica: <http://arstechnica.com/gadgets/news/2009/04/amazon-kindle-incidents-highlight-drm-limitations-once-again.ars> -- Rich Webb Norfolk, VAArticle: 141915
On Jul 16, 7:19=A0pm, rickman <gnu...@gmail.com> wrote: > Product(ProdHigh downto ProdHigh - MulOut'high) =3D> MulOut, > Product(ProdHigh - MulOut'high - 1 downto 0) =3D> OPEN, > According to Ben Cohen book, the product can not be split this way > using OPEN. =A0When I tried it with Synplicity it seems to accept this > syntax. =A0Ben's book is a bit older and refers to the '93 standard. =A0I > believe there is a newer VHDL standard, 200x. =A0Is this something that > has changed since '93 or is the Synplicity tool just being > magnanimous? =A0Should I change it so that it will work with other tools > or do most tools accept this? > Modelsim 6.4 (which is not the latest/greatest) reports the following (compiled with either VHDL '93 or '02) Error: Formal "xyz" must not be associated with OPEN when subelements are associated individually On the other hand, this particular item is something that I submitted to the VHDL standards group a few years back and was accepted at that time as a 'good' idea...maybe it made it into VHDL '08...if not theirs always VHDL 201x. Kevin JenningsArticle: 141916
In article <d41578a0-9128-4729-9f5c-c320762aaace@r33g2000yqn.googlegroups.com>, rickman <gnuarm@gmail.com> writes: >I find there are any number of aspects of the VHDL language that I >just do not remember and I am not going to make up flash cards to help >me remember. So I drag a half dozen VHDL books around with me when I >am working on VHDL (or much less frequently, Verilog; one of the books >covers both). > >I am getting tired of heaving the books up into the truck every time I >go to the lake and am starting to wonder if I should invest in some >good e-books on HDL. > >What do the rest of you prefer? Do you have both? Do you still need >to rely on your books or do you pretty well have the language down >pat? Several suggestions... Make flash cards. I'm thinking of small files with working examples so you can cut/paste. You only have to make one each time you have to look something up. Get second copies of the books to leave at the lake. (Or the ones you use the most.) Find a web site or 3 that has what you need. Personally, I prefer paper if I need anything more than a memory refresher. But it's hard to search so that only works if there is a good index or good table of contents or I know my way around well enough to quickly find what I'm looking for. Different people have different preferences. I'm happy with a data sheet printed on separate pages. A good friend hates paper but he's happy with PDFs. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 141917
>The point is that deep enough is often not a power of two and you >may not have the block RAM to waste on the unused portion. The >control circuitry would obviously be the same size since you >haven't reduced the number of address bits. I'd expect the control circuitry to be slightly larger for the non-power-of-two case. You need to wrap the address counters at 3/4 or 7/8 rather than just letting them roll over. Things may get more complicated if you want signals like almost-full, almost-empty, and half-full. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 141918
>I've an input 50MHz oscillator clock and I need following clock >signals : >- 50MHz clock (ADCs ENC+ pin) >- 50MHz 180 deg phase shifted (ADCs ENC- pin) Just a quick heads-up. How much jitter can to tolerate on your ADC clock? (jitter on the clock turns into noise on the output) Also, beware of clock packages with PPLs in them. You may want to start with a differetial clock and/or use a clock driver chip to send one copy to the ADC and another to the FPGA. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 141919
>< Then you have to write an assembler. We used to start with the one
>< leftover from the last project. Anybody got a handy sample?
>Easier to write macros for an existing macro assembler.
That's an interesting suggestion. Thanks.
It took me a while to figure out why that seemed strange.
Suppose I have 64 states and 2 branch bits. In the simple
case which is what I think Peter describes, you have to make
4 instructions per state. That's boring in the common
case where they are all identical. (but you can probably hack
the macros to do it)
It also takes up 4 times as much ROM space as you "need".
We used to build microcoded systems where the branching was done
by ORing the branch condition into the bottom address bits. That
reduces the cycle time slightly, but there is probably something
else that is limiting it anyway.
Typically, there was a field of the microcode that selected
the branch condition, a big mux, with 0 being hardwired to
select 0 (no branch) so the common case didn't use up any
extra ROM space.
Anyway, that approach needs a special pass in the assembler
to assign instructions to ROM locations.
We would use a syntax something like:
foo: blah blah, ?=, :more
more: blah ...
blah ...
blah ... :foo
more+1: blah blah :bar
The actual code is probably more complicated because of pipelines.
--
These are my opinions, not necessarily my employer's. I hate spam.
Article: 141920hey guys, I have an FPGA capturing binarizing an image and want to connect it to a PC for further analysis etc. What do you think would be the best protocol to use? The data itself is about 12.8 Mbits/second so was leaning toward 100Mbps ethernet implemented on the FPGA. Is this possible (plausible) without a soft processor, ie: just streaming the images straight from the FPGA RAM? Any links to relevant readings would be greatly appreciated so I could learn. GArticle: 141921
My replies to the original questions. >> 1. Is my take on the future of PCIe right? Will it become the only high speed interface in future mid- or high-level embedded CPUs? USB 3.0 is coming up. But it's going to target different applications. >> 2. Will future generations FPGAs be able to be programmed via PCIe? If so, when? I don't think so. For the same reason that current FPGAs cannot be programmed via USB or PCI. PCIe is a transport protocol. It requires an application, class driver, etc. I doubt PCI SIG is going to dedicate a new class just for programming FPGAs. >> 3. Is there a better way of configuring a current generation (e.g. V5 or V6) FPGA than via a bridge chip? Yes. You can use Master SPI or Master BPI modes without any glue logic. - evgeni http://OutputLogic.comArticle: 141922
>I suppose it makes some sense. The address decoders go to >enable lines that enable the signal coming out of the bit >cells onto the sense lines. If, for example, two enable lines >were active at once then two cells would be enabled onto the >same sense line. If the address goes metastable, it seems >that could happen. Presumably this is true for non-FPGA RAMs, too. Thanks, that's the hint I was fishing for. It's an unbuffered "output". At that level, the write isn't gated. The write driver for the sense line just overpowers the driver from the bit and smashes the bit to the new state. If two read lines are selected they may fight and one may "write" the other. That doesn't require any metastability. Just setup/hold can explain it all. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 141923
rickman wrote: <snip> > > Mul: multiply > PORT MAP ( > SysClk => SysClk, -- System clock, 12.288 MHz? > Start => Start, -- Load multiplican and init result > Multiplicand => LinDat, > Multiplier => std_logic_vector(AudioGain), > Product(ProdHigh downto ProdHigh - MulOut'high) => MulOut, > Product(ProdHigh - MulOut'high - 1 downto 0) => OPEN, > Done => Done > ); > > According to Ben Cohen book, the product can not be split this way > using OPEN. When I tried it with Synplicity it seems to accept this > syntax. Ben's book is a bit older and refers to the '93 standard. I > believe there is a newer VHDL standard, 200x. Is this something that > has changed since '93 or is the Synplicity tool just being > magnanimous? Should I change it so that it will work with other tools > or do most tools accept this? > > Rick Hi Rick, it was legal to do that (split an array up on the left of the association and leave parts of it open) in VHDL 87. It was made illegal in VHDL 93, i.e either the whole array may be left unconnected, or every element of the array must be associated, regards Alan -- Alan Fitch Senior Consultant Doulos – Developing Design Know-how VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 1AW, UK Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471573 http://www.doulos.com ------------------------------------------------------------------------ This message may contain personal views which are not the views of Doulos, unless specifically stated.Article: 141924
Gints <reganireland@gmail.com> wrote: > hey guys, > I have an FPGA capturing binarizing an image and want to connect it to > a PC for further analysis etc. What do you think would be the best > protocol to use? The data itself is about 12.8 Mbits/second so was > leaning toward 100Mbps ethernet implemented on the FPGA. Is this > possible (plausible) without a soft processor, ie: just streaming the > images straight from the FPGA RAM? Any links to relevant readings > would be greatly appreciated so I could learn. FT2232H (Only software on the PC side) or Cypress FX2 (Cy7C68013) (FX2 and PC programming needed) -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
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