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
Andrew, I suggest to throw away the 3020 and play with something more modern, even if it costs a few bucks ( sorry: pound in your case). Progress in FPGAs is so fast that one year in the evolution of FPGAs equals 15 years in the aging of humans. The XC3020 was introduced in 1988 ( the year I joined Xilinx), so it is now going on 15 years, which means 225 years in the life of humans. Do you want to exercise a veteran of the battle of Waterloo, somebody who has never seen a train or telephone? "O;d FPGAs do not die, they just fade away into obsolescence" ( to paraphrase Gen. McArthur) Greetings Peter Alfke ========================== Andrew Rogers wrote: > I have a really ancient XC3020 that I can play with (I am new to FPGA > and Xilinx tools). Its a PLCC and I have a socket so attaching wires > (for programming and attaching a few LEDs etc.) is simple unlike the > later TQFP packages. > > What I think I need is a .nph file for the Xilinx ISE software so that I > can use my XC3020. Is this file available? if so, where? and is this > all I need to be able to use Xilinx ISE Webpack software to target the > XC3020? > > Thanks > Andrew RogersArticle: 52001
IIRC, the 'problem' in the 4000 series only applied when using the
async mode for the RAMs. It has been quite a while tho, so I could be
suffering memory loss. In any event, Virtex works fine with initial
values. Typically, I use SRL16s instead of RAMs except for the very
rare instance where I can't make the SRL16 do what I need.
glen herrmannsfeldt wrote:
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3E3575FC.3C1C4D5F@andraka.com...
> > glen herrmannsfeldt wrote:
> > > "Ray Andraka" <ray@andraka.com> wrote in message
> > > news:3E32F64E.73A27950@andraka.com...
> > > > ... A LUT and a ROM are physically the same thing.
> >
> > >
> > > Last I knew (XC4000 days) it was not possible to initialize a
> LUT
> > > based RAM. The hardware couldn't guarantee against glitches on
> the
> > > R/W line at the end of initialization. So, in FPGA sense, LUT
> are
> > > ROM and not RAM.
> > >
> > > "Ray Andraka" <ray@andraka.com>
> > For Virtex and later, the problem with initializing RAM is no
> longer
> > there.
>
> I have the newer books, but I haven't looked for this since virtex
> came out. I do remember being surprised reading that the XC4000
> couldn't do it.
>
> Though this reminds me of a discussion in the days of 2102's (1Kx1
> static RAM), whether they would always power up to the same value.
> I was told that someone had thought of making a static RAM with an
> initial value. Then wondering if DRAM would tend to power up to
> the same value each time.
>
> -- glen
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 52002
Mauricio,
See my comments below.
Mauricio Lange wrote:
>
> Hi everybody!
> The PCI card I started to design months ago is near completion. Thanks
> a lot to all the people that answered my questions in this forum!
> Near completion means that it provides required functionality, but
> many details are in the road yet.
I hope you simulate the design on a simulator well before firing
up the card.
That how I developed a PCI IP core without using an oscilloscope or a
logic analyzer.
> Regarding configuration, I have difficult trying to interpret what the
> PCI spec says about the address assignment.
> I recall from the spec that the computer, at power-up time, reads the
> configuration registers, reads the BAR0, BAR1, etc, to find if any is
> implemented.
> I implemented the BAR0 register, that means that if the host writes
> data to it, when it reads the data back, some of the bits are set.
> Then, the host decides what address to assign to my device looking for
> the weight of the lowest bit set, so, if when BAR0 gives back
> 0xfffff000, the lowest bit is the 11th, or a decoding space of 2k,
> right?
> Then, my card should end with an address multiple of 2k, in any
> location of the memory space, that is what I understood.
>
That's correct.
> So, is the base address assignment a multipass cycle? I mean, the host
> first writes 0xffffffff to my BAR0, the it reads the data back, then
> it writes the assigned base address to my BAR0?
>
That's how the BIOS (firmware) determines the BAR size.
> I did the following: preset my BAR0 register to 0x00000005 (the
> BAR0(0) bit indicates the space, memory or i/o) and get, as result,
> the following address assigned: 0x02000001, what could that possibly
> mean?
>
You should be aware that the PCI specification says devices
should not have I/O mapped address larger than 256 bytes per BAR.
That has to do with IBM PC/AT architecture's I/O mapping limitations.
If you want address space larger than 256 bytes, it has to be memory
mapped.
Also, if your device's BAR type is I/O BAR, bit 2 of the BAR cannot be
hardwired to 1 (If you want, it can be hardwired to 0, however.), or
start up as 1 after reset (PCI specification assumes that configuration
registers should start up as 0, unless hardwired to a certain value.).
> A curious thing: The card is double layer, carefully laid out to
> minimize the lenghts (that never, never aproached to the 1.5 inches
> that the spec insists on using) and the number of vias thru each trace
> has to pass; uses a socketed PLCC84 old FPGA, that surely doesn't
> comply with the required 10pf per pin max.
> That only description could give me fever not a long time ago,
> thinking of the bus disasters it could cause. But, to my surprise, not
> even a wire 10 inches long, soldered to a via (!!!) in my card, could
> disrupt the normal behavior of the bus. The bus is tougher than I
> thought.
>
> Excuse me the lenght of the question!
>
> Mauricio Lange
What FPGA are you using?
Sounds like a real old one to me.
Anyway, if you are using an FPGA that still supports PLCC package, your
design may not meet PCI's setup time because the FPGA is likely very
slow.
PCI specification says, for 33MHz PCI, the PCI device needs to latch
data from the bus within 7ns (setup time, Tsu), and send data within
11ns (clock-to-output valid, Tval).
However, in practice, you will have some clock skew within the FPGA, so
you will have additional 1ns to 2ns to latch the data.
Still, 8ns to 9ns is not much time, and if you really want to meet it,
you will have to resort to optimizing your design (i.e., Reducing the
levels of logic) or floorplanning.
But I am aware that even you violate the Tsu or Tval by several ns, the
card will still likely work because the first version of the PCI IP core
I developed violated Tsu and Tval by 3ns to 4ns respectively, but it
worked fine at 33MHz.
If you really want to stick to the specification, consider using Virtex
or Spartan-II because they are so much faster, it is much easier to meet
timings.
Kevin Brace (If someone wants to respond to what I wrote, I prefer if
you will do so within the newsgroup.)
Article: 52003Peter Alfke wrote: > Andrew, I suggest to throw away the 3020 and play with something more > modern, even if it costs a few bucks ( sorry: pound in your case). > Progress in FPGAs is so fast that one year in the evolution of FPGAs equals > 15 years in the aging of humans. > The XC3020 was introduced in 1988 ( the year I joined Xilinx), so it is now > going on 15 years, which means 225 years in the life of humans. > > Do you want to exercise a veteran of the battle of Waterloo, somebody who > has never seen a train or telephone? > "O;d FPGAs do not die, they just fade away into obsolescence" ( to > paraphrase Gen. McArthur) > > Greetings > Peter Alfke > ========================== > Andrew Rogers wrote: > > >>I have a really ancient XC3020 that I can play with (I am new to FPGA >>and Xilinx tools). Its a PLCC and I have a socket so attaching wires >>(for programming and attaching a few LEDs etc.) is simple unlike the >>later TQFP packages. >> >>What I think I need is a .nph file for the Xilinx ISE software so that I >>can use my XC3020. Is this file available? if so, where? and is this >>all I need to be able to use Xilinx ISE Webpack software to target the >>XC3020? >> >>Thanks >>Andrew Rogers > > Where can I buy a new Spartan in very small quantities and a low price? What is the lowest cost, modern FPGA that the ISE Webpack can target? The electronic component suppliers tend to have large minimum order quantities. Maybe Xilinx would consider offering some free samples:) Thanks Andrew RogersArticle: 52004
On Tue, 28 Jan 2003 17:12:50 GMT, "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote: > >"Lars Unger" <larsu@ida.ing.tu-bs.de> wrote in message >news:Pine.LNX.4.50.0301281035570.8058-100000@wichtel.ida.ing.tu-bs. >de... >> Hi, >> >> for my thesis I need an implementation of an 1024-bit adder for a >Xilinx Virtex >> FPGA (XCV600). Up to now i have tried to add all bits in one step >with the >> following approaches: >> > >(snip) > >I would say that a pipelining approach should help. I am >interested to know what kind of problem would use a 1024 bit adder. > >-- glen > The only application I can think which needs anywhere near 1024 bit inputs is encryption, digital signatures etc. but those applications usually don't need straight adders. Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 52005
frank wrote: > > Can anyone suggest any litterature concerning ring oscillators in fpgas ? I don't think there is anything formal - this is quasi analog stuff in a digital world. Even getting some tools to 'keep' a ring osc is non-trivial :) A ring Osc is relatively noisy, and a very good thermometer. We did a teaching/test excercise that displayed the Fosc on a LED readout on a Demo board, display LSB was resolving in the femto second region, but the jitter and noise was magnitudes higher. One part in 10,000 to 100,000 is common RC osc short term stability, so a Ring osc will not better that. Locking/jumping issues will most likely exclude doing this on one die, 1ps is finer granularity than any delay element in a FPGA, but you CAN get continuous variable times by varying Vcc ( or temp :) ( and then you have made a VCO ) That said, 1ps is 1 part in 2000 at 500MHz, so is not stellar stability. You will need a VCO structure, to get linear time, so could try an LC Osc with Varicap, or tiny logic gates with controlled Vcc. The higher the L Q, the lower the jitter will be. I seem to recall Helical coils used in VHF radios ? -jg > - Frank > > frank8017@excite.com (frank) wrote in message news:<60bf6cad.0301201203.7b4a0ac5@posting.google.com>... > > Hello, > > > > I was wondering if it is possible to implement 2 ring oscillators on > > an fpga (xilinx or altera) with very similar frequencies (difference > > in periods: ~1ps, approximate frequency: 100-500MHz). It is paramount > > that the 2 frequencies can be controlled to be able to acheive the > > period differential of ~1 ps. > > btw, what would be a reasonable jitter value for an fpga-implemented > > ring oscillator ?Article: 52006
Hello gurus!
Does anyone have any ideia about how to create a *real* Random Number
Generator using an APEX20K FPGA? If no, is there any IC that can do that?
I would be very pleased if someone could give me at least some ideas.
Thank you
Roberto Gallo
Article: 52007Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<3E357B74.2090208@flukenetworks.com>... > Alain wrote: > > How specify with XST synthetiser (Xilinx) to encode FSM in "safest > > way", . . . > > I previously use FpgaExpress and it had this option... > > > If XST has no "safe" setting for one-hot, consider using > binary encoding as it is inherently safe. > > -- Mike Treseler A google search on - XST one-hot comes up with the foll. links - http://toolbox.xilinx.com/docsan/xilinx4/data/docs/cgd/f6.html http://www.xilinx.com/xlnx/xil_ans_display.jsp?BV_SessionID=@@@@0361207789.1043783564@@@@&BV_EngineID=ccccadchggigjemcflgcefldfgldgji.0&getPagePath=15708 Hope this helps, Vikram.Article: 52008
> Verilog has an API (called PLI) to "real" > programming languages like C++ and even (god forbid) VB. VB. Bwahahahaha. He he he. Time to go change my pants. MyrenArticle: 52009
Roberto, you have to define your idea of "real". Obviously variatons on LFSRs can easily generate pseudo-random numbers, but you seem to be looking for something better. How much better? Peter Alfke ================= Roberto Gallo wrote: > Hello gurus! > > Does anyone have any ideia about how to create a *real* Random Number > Generator using an APEX20K FPGA? If no, is there any IC that can do that? > I would be very pleased if someone could give me at least some ideas. > > Thank you > > Roberto GalloArticle: 52010
Hello folks, I'm trying to sort out how to use jtag for things other than programming a chip. I'm using the Xilinx webpack 5.1, including iMPACT. My goal is to shift an arbitrary bit pattern onto the outputs of a cpld. I've tried two ways of doing this: Method 1: - Write a script of JTAG commands in SVF or STAPL - Somehow run this script (I can create .svf/.stapl's in impact, but I don't think I can run them) Method 2: - Add test vectors to the jedec output. I've found instructions on how to do this with ABEL, but nothing on adding them in a VHDL project. - Run "functional test". My questions are: - Can I run SVF's/STAPL's from iMPACT? - Can I add test vectors to a .jed when the project is a VHDL project? - Where do BSDL files come into this? Thanks for your help! Ryan.Article: 52011
"Ryan Gammon" <rggammon@alumni.uwaterloo.ca> schrieb im Newsbeitrag news:4vCZ9.2292$fO5.272948@ursa-nb00s0.nbnet.nb.ca... > Hello folks, > > I'm trying to sort out how to use jtag for things other than programming a > chip. I'm using the Xilinx webpack 5.1, including iMPACT. > > My goal is to shift an arbitrary bit pattern onto the outputs of a cpld. AFAIK the JTAG port in the Xilinx CPLDs is for programming only. Have a look in the BSDL files. -- MfG FalkArticle: 52012
"Rob Finch" <robfinch@sympatico.ca> wrote in message news:<mk2Z9.716$qg1.153709@news20.bellglobal.com>... > I prefer Verilog, I think it partly has to do with linguistics. The issue I > have is not with the number of characters typed, I find it much easier to > read than VHDL. For instance, which is harder to read "downto" or ":" ? foo (31 downto 0) makes clear which bit is the MSB. [31:0] foo also makes clear which bit is the MSB. foo (X downto Y) makes clear which bit is the MSB. [X:Y] foo does not. > Generally I find fewer characters easier to read to a point. What is a > "std_logic_vector" ? The concatonation of three different components > confuses me. It really is just one idea, so why represent it with three > different meaning components ? It's a type. Specifically, it's a vector of std_logics. A std_logic, of course, has several possible logic states. Granted, most of the logic states are not useful for synthesis, but they *are* useful when simulating. > If it's a standard, then why do I have to > type in 20 characters ? Why can't I just type "vec" ? Well, define your own type called vec and be done with it. > Having a lot of different strictly defined types is not necessarily a good > thing. It all depends upon what the goal is. Without strictly defined types, > I find it easier to generalize my understanding of code. Strictly-defined types help catch errors at COMPILE time, which is when it's easiest to fix them. Consider this: VHDL has built-in linting. > Something I don't understand about VHDL: why would one use different RTL and > behavioural code ? If you're testing something, wouldn't you want the code > being tested to be the same as the code synthesized ? You might want to read Janick Bergeron's book, which answers that question quite nicely. Consider: the test bench does not need to be synthesizable, so it can be written in a way that simulates faster. And so forth.... -aArticle: 52013
You won't geta truly random output out of a digital logic circuit, with the
possible exception of an improperly treated asynchronous input (I wouldn't
rely on that for any particular distribution though). Digital designs are
suppposed to be deterministic. That said, you can get a good pseudo-random
generator, which generates a known sequence, but without knowing the
generator it would be hard to predict it. Simple PN generators are done with
linear feedback shit registers. The crypto community has taken these further
to get less predictability and therefore harder to break encryption. You
might try googling on LFSR, Pseudo-random, encyption, cipher, etc to see what
comes up.
You also didn't mention the desired distribution. The PN sequeunces are
generally uniform distributions. If you need a gaussian source, you can use
the central limit theorem to combine a number of PN sources to obtain a
gaussian distribution. The individual PN sources need to be independent over
the observation period, which is to say that they can be identical so long as
they are seed so that no two of them produce the same sequence within some
finite amount of time (LFSRs can be set up for periods of thousands of years,
so it is just a matter choosing seeds that aren't close to one another).
Roberto Gallo wrote:
> Hello gurus!
>
> Does anyone have any ideia about how to create a *real* Random Number
> Generator using an APEX20K FPGA? If no, is there any IC that can do that?
> I would be very pleased if someone could give me at least some ideas.
>
> Thank you
>
> Roberto Gallo
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 52014Andrew Rogers wrote: > Peter Alfke wrote: > > Andrew, I suggest to throw away the 3020 and play with something more > > modern, even if it costs a few bucks ( sorry: pound in your case). > > Progress in FPGAs is so fast that one year in the evolution of FPGAs equals > > 15 years in the aging of humans. > > The XC3020 was introduced in 1988 ( the year I joined Xilinx), so it is now > > going on 15 years, which means 225 years in the life of humans. > > > > Do you want to exercise a veteran of the battle of Waterloo, somebody who > > has never seen a train or telephone? > > "O;d FPGAs do not die, they just fade away into obsolescence" ( to > > paraphrase Gen. McArthur) > > > > Greetings > > Peter Alfke > > ========================== > > Andrew Rogers wrote: > > > > > >>I have a really ancient XC3020 that I can play with (I am new to FPGA > >>and Xilinx tools). Its a PLCC and I have a socket so attaching wires > >>(for programming and attaching a few LEDs etc.) is simple unlike the > >>later TQFP packages. > >> > >>What I think I need is a .nph file for the Xilinx ISE software so that I > >>can use my XC3020. Is this file available? if so, where? and is this > >>all I need to be able to use Xilinx ISE Webpack software to target the > >>XC3020? > >> > >>Thanks > >>Andrew Rogers > > > > > > Where can I buy a new Spartan in very small quantities and a low price? Not sure, but I thought someone on this newsgroup suggested Digikey. > What is the lowest cost, modern FPGA that the ISE Webpack can target? Spartan II and Spartan IIE are in the ISE WebPACK. By the way, adding the 3020.nph file to the WebPACK will not work. Steve > The electronic component suppliers tend to have large minimum order > quantities. Maybe Xilinx would consider offering some free samples:) > > Thanks > Andrew RogersArticle: 52015
I'm at my first not trivial VHDL design, so probably this is really a stupid
question.
I tried to search FAQ, Xilinx website, and to experiment by myself, but now
I would like some suggestion from people more able than me..
Please take a look at this simple app; it's just the simplest source I could
post to show my problem. It's just an example, meaningless by itself.
I'm using ISE 5.1 + SP3, under XST; target is a Spartan IIE, XC2S100, -7.
In my real app (video frame grabber/splitter/effects), I need to sample an
incoming digital video stream at every rising edge of "CLK_IN".
Internally I use a DLL to multiply it by two, to manage an sdram controller,
fifos, and video effects.
I need to know on wich of two consecutive rising edges of CLK 2X I have new
data coming from outside.
I'd prefer to use just CLK 2X signal in the whole design, and just use an
"enable" signal to mark edges to use for sampling external data, at half
CLK2X frequency.
I know it's probably not the most elegant way, but... the 90 degrees clock
output (1X freq.) is low on CLK2X "sampling" rising edges, and high on "data
ready" CLK2X rising edges. I'm sure there are better way... but now I'm just
curious to understand why it doesn't works.
If I use the CLK 90, and its inverted version, timing closure is okay.
If I use the CLK 270, and its inverted version, it fails timing closure.
Why ? CLK 90 and CLK 270 out from a DLL should one the inverted version of
the other, in first approx.
I tried to sample them with CLK2X... no avail.
The following VHDL "toy" source complies to constraints or not; cfr. lines
marked with "NOTE 1" and "NOTE 2".
------------------------
-- Search for NOTE 1 and NOTE 2 lines; using the "clk_90" version, works ok;
-- using clk_270 version, assumes 7.5 ns as a requirement, and it fails.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity prob is
Port (
clk_in: in std_logic; -- clock input; 27 mhz
din : in std_logic_vector(7 downto 0); -- data input bus; sample on
rising edge of clk_in
dout: out std_logic_vector(15 downto 0) -- sampled data output;
synchronized to clk2x;
);
end prob;
architecture Behavioral of prob is
signal sample: std_logic_vector(7 downto 0); -- din, sampled at rising
edge of clk2x, when clk_en high.
signal ram_out: std_logic_vector(15 downto 0); -- data out of block ram
signal clk_in_int: std_logic; -- buffered clk_in
signal clk2x_int: std_logic; -- do not use, not buffered
signal clk2x: std_logic; -- buffered internal clock
signal clk_90: std_logic;
signal clk_270: std_logic;
signal sample_en: std_logic; -- true before clk2x rising edge coincident
with rising clk_in
signal data_rdy: std_logic; -- clk_90; negato, ottengo sample_en.
attribute BOX_TYPE: string; -- una sola volta (dichiariamo il tipo).
component CLKDLLE
-- Cfr. Answers #11537: CLKDV_DIVIDE dev'essere un attributo per sintesi,
un generic per simulazione.
generic (
CLKDV_DIVIDE : real := 2.0;
STARTUP_WAIT : boolean := TRUE; -- blocca startup finche' non e' locked.
DUTY_CYCLE_CORRECTION : boolean := TRUE
);
port ( CLKIN : in std_logic := '0';
CLKFB : in std_logic := '0';
RST : in std_logic := '0';
CLK0 : out std_logic := '0';
CLK90 : out std_logic := '0';
CLK180 : out std_logic := '0';
CLK270 : out std_logic := '0';
CLK2X : out std_logic := '0';
CLK2X180 : out std_logic := '0';
CLKDV : out std_logic := '0';
LOCKED : out std_logic := '0');
end component;
-- cfr. Answers Database #7419
attribute CLKDV_DIVIDE: string;
attribute DUTY_CYCLE_CORRECTION: string;
attribute STARTUP_WAIT: string;
attribute BOX_TYPE of CLKDLLE: component is "BLACK_BOX";
attribute CLKDV_DIVIDE of CLKDLLE: component is "2.0"; -- needs XST
>=5.1 (real)
attribute DUTY_CYCLE_CORRECTION of CLKDLLE: component is "TRUE"; -- 50% duty
attribute STARTUP_WAIT of CLKDLLE: component is "TRUE";
component IBUFG port(I: in std_logic; O: out std_logic); end component; --
clk_in
attribute BOX_TYPE of IBUFG : component is "BLACK_BOX";
component BUFG port(O: out std_logic; I: in std_logic); end component; --
clk2x
attribute BOX_TYPE of BUFG : component is "BLACK_BOX";
component RAMB4_S8_S16
port (
ADDRA: IN std_logic_vector(8 downto 0);
ADDRB: IN std_logic_vector(7 downto 0);
DIA: IN std_logic_vector(7 downto 0);
DIB: IN std_logic_vector(15 downto 0);
WEA: IN std_logic;
WEB: IN std_logic;
CLKA: IN std_logic;
CLKB: IN std_logic;
RSTA: IN std_logic;
RSTB: IN std_logic;
ENA: IN std_logic;
ENB: IN std_logic;
DOA: OUT std_logic_vector(7 downto 0);
DOB: OUT std_logic_vector(15 downto 0));
END component;
attribute BOX_TYPE of RAMB4_S8_S16 : component is "BLACK_BOX"; -- sopprime
warning "Generating... black box ..."
begin
CLKIN_PAD: IBUFG port map (I=>clk_in, O=>clk_in_int);
CLK2X_OUT_BUF: BUFG port map (I=>clk2x_int, O=>clk2x);
data_rdy <= not sample_en; -- ****** NOTE 1: use this for
clk_90; it works
-- sample_en <= not data_rdy; -- ****** NOTE 1: use this for
clk_270; it doesn't
dll_core: CLKDLLE
port map (
CLKIN=>clk_in_int, CLKFB=>clk2x, RST=>open,
CLK0=>open, CLK180=>open,
CLK90=>clk_90, CLK270=>clk_270,
CLK2X=>clk2x_int,
CLK2X180=>open, CLKDV=>open, LOCKED=>open);
-- block ram
bram1: RAMB4_S8_S16 port map (
-- Port A (input, 8 bit)
CLKA => clk2x,
RSTA => '0', -- reset A;
ADDRA => "000000000", -- just an example...
DIA => sample,
DOA => open,
WEA => '1',
ENA => data_rdy, -- write enable
-- Port B (output, 16 bit)
CLKB => clk2x,
RSTB => '0',
ADDRB => "00000000",
DIB => "0000000000000000",
DOB => ram_out,
WEB => '0',
ENB => '1'
);
clk_en_proc: process(clk2x)
begin
if rising_edge(clk2x) then
sample_en <= clk_90; -- ****** NOTE 2: use this for
clk_90; works ok
-- data_rdy <= clk_270; -- ****** NOTE 2: use this for
clk_270; doesn't work.
end if;
end process;
sample_proc: process(clk2x)
begin
if rising_edge(clk2x) then
if sample_en = '1' then
sample <= din;
end if;
end if;
end process;
bram_sample: process(clk2x)
begin
if rising_edge(clk2x) then
dout <= ram_out;
end if;
end process;
end Behavioral;
----------------------------------------------------------------------------
------ end
I'm using this simple .UCF constraint file:
TIMESPEC "ts_clk_in" = PERIOD "clk_in_grp" 30 ns HIGH 50 %; # 27 Mhz
OFFSET = IN 10 ns BEFORE "clk_in"; # default pad to clk
OFFSET = OUT 16 ns AFTER "clk_in"; # default clk to out
NET "clk_in" TNM_NET = FFS "clk_in_grp";
NET "clk_in" LOC = "p129"; # gck3
---------------------------
Seems that XST generates a "7.5 ns" requirement, but I don't understand why
just in one of the two cases.
That same requirement dissolves if I substitute the block ram with a bank of
FF. Why ?
At the block ram input port, all signals are already synchronized to CLK2X;
why timing requirement should change so drastically ?
With the same block ram that fails closure, if I generate the post P&R
timing report with
"advanced" and "verbose" option (so, it ignores the constraints), the "7.5
ns" requirement disappears.
I think I'm wrong in something very silly; perhaps the constraint
declarations...
What's going on ?
Article: 52016Hi, I'm writing a small processor core as a hobby. It is a small 16-bit core with about 20 instructions, including simple ALU functions, memory read and writes, stack operations, ... All instructions can be conditional (depending on the value of my 'working register'). Up to three operations can be combined in a single opcode, although not all combinations are possible. I was wondering if it would be do-able for me to port the GNU C-compiler to my own core. I guess it is possible, since the ARM has conditional instructions too, and it has multiple instructions in one opcode too. But how long would that take me ? Anybody any experience in porting GNU-C to a similar core as mine ? Are there any alternatives ? The LCC compiler isn't an option I think, because their original target core doesn't have multiple-instructions or conditional code. Any comments are appreciated, MarcArticle: 52017
Falk, Actually, most Xilinx CPLDs support many other JTAG operations, including EXTEST and INTEST. attribute INSTRUCTION_OPCODE of xc9536xv : entity is "BYPASS ( 11111111)," & "CLAMP ( 11111010)," & "ISPEX ( 11110000)," & "EXTEST ( 00000000),"& "FBLANK ( 11100101),"& "FBULK ( 11101101),"& "FERASE ( 11101100),"& "FPGM ( 11101010)," & "FPGMI ( 11101011)," & "FVFY ( 11101110)," & "FVFYI ( 11101111)," & "HIGHZ ( 11111100),"& "IDCODE ( 11111110),"& "INTEST ( 00000010),"& "ISPEN ( 11101000)," & "ISPENC ( 11101001)," & "SAMPLE ( 00000001)," & "USERCODE ( 11111101)"; Regards, Michol Bauer Falk Brunner wrote: > "Ryan Gammon" <rggammon@alumni.uwaterloo.ca> schrieb im Newsbeitrag > news:4vCZ9.2292$fO5.272948@ursa-nb00s0.nbnet.nb.ca... > > Hello folks, > > > > I'm trying to sort out how to use jtag for things other than programming a > > chip. I'm using the Xilinx webpack 5.1, including iMPACT. > > > > My goal is to shift an arbitrary bit pattern onto the outputs of a cpld. > > AFAIK the JTAG port in the Xilinx CPLDs is for programming only. Have a look > in the BSDL files. > > -- > MfG > FalkArticle: 52018
Peter Alfke wrote > Andrew, I suggest to throw away the 3020 and play with something more > modern, even if it costs a few bucks ( sorry: pound in your case). RS Components is still distributing the XC3020 for Xilinx ;-)Article: 52019
I make a big distinction between spare-part availability ( or parts to make it possible to keep manufacturing old designs), and the insanity of using of obsolete parts for starting a fresh design. Yes, we keep XC3020s available, but it would be silly to use them for a new design... BTW, Whitney still offers spare parts for the Ford Model T of 1908. Good car at its time ! Peter Alfke ======================= Tim wrote: > Peter Alfke wrote > > Andrew, I suggest to throw away the 3020 and play with something more > > modern, even if it costs a few bucks ( sorry: pound in your case). > > RS Components is still distributing the XC3020 for Xilinx ;-)Article: 52020
Does anyone know of a analog-in analog-out DSP development for a Xilinx fpga? I don't need much fpga logic. I just want something into which I can burn my iir filter design so the customer can see what it does before we build it into his system. The frequencies are in the audio range so 20Ksps is fast enough. -- Pete Dudley Arroyo Grande SystemsArticle: 52021
sir, i am first trying to implement single data read and write to the local side. waiting for reply praveenArticle: 52022
Praveen, Are you saying that you are trying to clone PLX 9050? If that is what you are trying to do, you will need to the PCI specification so that you will understand the PCI bus protocol. The PCI specification's Appendix B will show you an example of how to build a target and a initiator state machine, but you should only use them as a reference, and not directly copy everything shown there because they are not detailed enough (The actual implementation of a PCI interface is harder than what Appendix B implies.). Of course, I am sure you will also need as much documentation as possible from PLX about the chip like its register map and local bus protocol (I am sure you already got that.). It will probably make your job somewhat easier if a simulation model of PLX 9050 exists, and you can run it on an HDL simulator. Kevin Brace (If someone wants to respond to what I wrote, I prefer if you will do so within the newsgroup.) praveen wrote: > > hello sirs/friends > i am writing vhdl code for PCI bridge to be specific i am trying to > implement PLX 9050 bridge. I have understood the protocol. But i donot > know the internal design details of that chip. i am total lost. > please help me . if you have done any project of this kind please send > the design details of it. u can mail it my email id. how to > start????.module level?????how??? > > waiting for ur reply > thanks in advance > praveenArticle: 52023
Kevin, Glen, thanks for the replys. > I hope you simulate the design on a simulator well before firing > up the card. > That how I developed a PCI IP core without using an oscilloscope or a > logic analyzer. I didn't use a logic analyzer nor an oscilloscope. Fired it up and worked. I did the design part by part, so, the first time the card was alive, the only thing it could do was a Target I/O Write!! I used a K6 class PC, booted to DOS and used DEBUG. I connected a 7 segment display to the multi-purpose header of my card and used it as the debug output. Now, I dont have the thousand or so bucks required to get a number from the PCI Group, so, I am playing with the PCI numbers already registered. :) > What FPGA are you using? > Sounds like a real old one to me. > Anyway, if you are using an FPGA that still supports PLCC package, your > design may not meet PCI's setup time because the FPGA is likely very > slow. > PCI specification says, for 33MHz PCI, the PCI device needs to latch > data from the bus within 7ns (setup time, Tsu), and send data within > 11ns (clock-to-output valid, Tval). > However, in practice, you will have some clock skew within the FPGA, so > you will have additional 1ns to 2ns to latch the data. > Still, 8ns to 9ns is not much time, and if you really want to meet it, > you will have to resort to optimizing your design (i.e., Reducing the > levels of logic) or floorplanning. > But I am aware that even you violate the Tsu or Tval by several ns, the > card will still likely work because the first version of the PCI IP core > I developed violated Tsu and Tval by 3ns to 4ns respectively, but it > worked fine at 33MHz. > If you really want to stick to the specification, consider using Virtex > or Spartan-II because they are so much faster, it is much easier to meet > timings. > This is my first card, and I had to resort to what I had in hand. Xilinx donated a kit from XESS with an XC4010XL two years ago to my university. I am using that IC. In my next project (coming soon, I hope!), I will be using a Spartan or a Virtex, no doubt of it! Mauricio LangeArticle: 52024
hello, i am praveen kumar , a student doing the vhdl code of PCI bridge. can u please give the internal design detial(design document) of the PCI bridge which you have implemented. you can mail it to my email id praveenkumar1979@rediffmail.com).i will be greatful to you. waiting for ur reply thanks in advance praveen
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