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
Greetings, I'm am trying to implement a PS/2 Keyboard interface in a Virtex-E device. The problem is that the keyboard uses 5V TTL logic whereas the Virtex-E uses 3.3V LVTTL. What I would like to know is, is it possible to connect these two directly? According to a Xilinx tech note (http://www.xilinx.com/products/virtex/techtopic/vtt002.pdf), an input pad on the Virtex-E is 5V tolerant providing an 100 ohm external resistor is used. It also says that it can output to a 5V TTL device providing nothing on the receiving device pulls a signal greater than 3.6V. However, the data and clock lines for the PS/2 interface are bi-directional. It seems from this document that the bi-dir IO buffers aren't 5V tolerant. Also what do I do if the keyboard drives more than 3.6V? How do I add an external pullup resistor? I'm a complete novice so a explaination that assumes zero knowlege would be really appreciated! Cheers, JonBArticle: 46151
>Whether you really care about the initial state is dependent on your >application. I find that most of my designs are tolerant to wrong >initial states, so I don't bother doing anything about it. I got an "interesting" education on that topic many years ago. I had a simple one-hot state machine with 4 states. Just a single bit running around in a circle. One FF was inverted so that 0000 was a valid state and reset would start right. How simple can something be? It had a bug. The GSR signal hit one CLB before the other. It ended up with 2 bits running around. I've been more careful/paranoid since. It may not take any more code/logic, but it does take more thought. That bug was just a simple setup/hold problem. If you want to get serious, consider metastability. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 46152
Tom, There is: http://ptolemy.eecs.berkeley.edu/ which is incredibly useful and powerful. I have been told that some of the top three wireless companies use this tool (and its free). It can go from GUI to HDL .... although you may have to develop some libraries yourself for functions you can't find already done. Don't re-invent the wheel. This code is partially delivered in some commercial products now according to the grape-vine. One nice thing about universities is the massive amount of labor that is channeled into providing useful bits and pieces of code when a project like this really comes together. Berkeley Unix was another useful project that this reminds me of. Of course, having Ken Thompson right there at Berkeley for the summer helped (Bell Labs told him to "stop messing around with that 'c' or else he'd have to find a job elsewhere"). Austin Tom Loftus wrote: > I am an experienced ASIC designer with a little bit of DSP coursework > and I would like to learn more about implementing DSP algorithms in hardware. > I think that implementing various hardware architectures in FPGA's > would be a useful learning exercise which could be done fairly quickly > and cheaply using my available PC resources at home and work. > > I have access to Verilog/VHDL simulation tools and am familiar with the available > Web baseline FPGA tools. The pieces I think I am missing are the visualization > and verification portion of the development: > > Visualization - I want to be able to take input and output data streams in > both the time and frequency domain and graphically display them. > > Verification - I need a baseline with which I can compare my hardware > implementation to verify it is working correctly. > > I know something like Matlab or Mathcad would probably do what I am looking > for, but they seem rather expensive. > > Can anyone offer other ideas? Does what I am planning sound reasonable? > > TomArticle: 46153
"HenningB" <HenningBahr@web.de> wrote in message news:58f8478d.0208200307.2546a7c4@posting.google.com... > Hi all, > > I have designed a simple frequency divider, existing mainly of 15 > flip-flops. Ambit BuildGates is my synthesis tool. I am getting the > following results when my target technology is a 300k gate-array > technology from LSI: > > Worst path delay: 1.73 ns > Cell Area: 279 > > And these are the results when using a standard-cell 0.35 um > technology: > > Worst path delay: 1.92 ns > Cell Area: 13,304 > > Why is there such a huge discrepancy between the cell areas? The first thing to check is the definition of "cell". Most people use 2 input NAND gate equivalents. Perhaps the larger figure is in square microns, and the smaller one in 2 input nand gates? Alan <snip>Article: 46155
Hi,
Actually i think i will try to explain my problem little bit more
clearly. I have an architecture and i am trying to implement several
applications in them.
Suppose if i want to implement the bandpass filter algorithm in my
architecture, i have generated the text file which contains the
interconnection matrices for the entire cycle of bandpass filter ,
which is namely algorithm containing 9 mathematical steps . In this
way i would have similarly around 20 steps for some other application
and i have generated text files which contain these signals for every
step.
So what i would like to do is to try to execute these applications on
board step by step and for that , i have to somehow be able to read
the values from the text files ( may be i don't know , but somehow put
these data on board in some way or the other) and the controller
should be able to do it.
I think i have explained more about my problem and can u please give
me some insight on this.
Thanks,
Ram.
John Williams <j2.williams@qut.edu.au> wrote in message news:<3D61DBDB.C9D165FB@qut.edu.au>...
> Hi Ram,
>
> I'll have a stab at this one. As far as I'm aware, you can't "import a
> text file" into FPGA memory without a rgeat deal of external circuitry
> etc, communications interfaces and so on. I think what you want to do
> is to include the contents of your text file at synthesis time, so the
> data is embedded in the resulting bitstream.
>
> It sounds like you're doing some kind of signal routing. So, do you
> want one bitstream that has a particular interconnection table, and
> another bitstream with a different table, and be able to switch between
> the two (by reconfiguring)? Or, would you like to place several
> interconnection tables in one design (bitstream), and switch between
> them in logic?
>
> Either way, instead of including text files in your VHDL, you might want
> to consider using constant arrays. They get synthesised as ROMs (and
> possibly RAM with the write ports unconnected?).
>
> For a constant array, use something like this:
>
> entity my_design
> port
> (some_input : std_logic_vector(3 downto 0));
> ...
>
> end my_design;
>
> architecture ...
>
> subtype connection_entry is std_logic_vector(3 downto 0); -- for
> example
>
> type connection_table is array(0 to 7) of connection_entry;
>
> constant table1 : connection_table := ("0001","0010","0101" ...);
>
> begin
>
> some_output <= table1(to_integer(some_input));
>
> end
>
> I hope you get the idea.
>
> In this way, you could have multiple connection tables in your design,
> the choice of which is decided in real time, eg:
>
> architecture ...
> constant table1 : ...
> constant table2 : ...
> constant table3 : ...
> -- and so on
>
> begin
> output <= table1(to_integer(some_input)) when selection="000" else
> table2(to_integer(some_input)) when selection="001" else
> ... -- and so on
>
> end
>
> Alternatively, you could simply have a different design (bitstream) for
> each connection table.
>
> To automatically generate these things you can write a simple code
> generator in a high level language (even VHDL!).
>
> Reply in the newsgroup if you'd like some more info.
>
> Hope this is helpful,
>
> Rgds,
>
> John
Article: 46156
Tjena Patrick,
I can't say that I can represent Xilinx support in this issue
but I remember a similar problem I had a while ago.
The problem was that the clocks to the bram started at time 0
but the reset signal was not valid yet.
If you follow the VHDL simulation, the clock will arrive to the
BRAM when the address inputs signals are still invalid ('U').
The address signals will be valid in a few deltas but that is still to la=
te
for the simulation model.
The situation of a active clock input but invalid address signals will se=
t
the memory contents to 'X'.
The fix I did was to drive the reset before a started to drive the clock.=
I hope that this will fix your problem since it fixed mine.
Med v=E4nliga h=E4lsningar
G=F6ran
Patrik Eriksson wrote:
> When I simulates the following code this warning message is displayed a=
t
> time 0ns.
>
> # ** Warning: Invalid ADDRESS: XXXXXXXXXX. Memory contents will be set
> to 'X'.
> # Time: 0 ps Iteration: 3 Instance: /theram
>
> This means that I can't simulate with correct INIT values!!
> All addresses and control signals are constant but the clock inputs are=
> toggled.
>
> Have I done anything stupid? Is there an error in the simulation model?=
> This code is a debug version of my real design just to track the
> simulation error.
>
> I thought that if WEx is de-asserted nothing should happen to the memor=
y
> contents whatever the other signals looks like.
>
> /Patrik Eriksson
> -----------
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_unsigned.all;
>
> -- synthesis translate_off
> library unisim;
> -- synthesis translate_on
>
> entity bram_tb is
>
> end entity bram_tb;
>
> architecture sim of bram_tb is
>
> component BUFG
> port (
> I : in std_logic;
> O : out std_logic);
> end component;
>
> component IBUFGDS_LVPECL_33
> port (
> O : out std_ulogic;
> I : in std_ulogic;
> IB : in std_ulogic);
> end component;
>
> component DCM
> -- synthesis translate_off
> generic (
> DLL_FREQUENCY_MODE : string :=3D "LOW";
> CLKOUT_PHASE_SHIFT : string :=3D "NONE";
> PHASE_SHIFT : integer :=3D 0;
> CLKFX_MULTIPLY : integer :=3D 4;
> CLKDV_DIVIDE : real :=3D 2.0
> );
> -- synthesis translate_on
> port (
> CLKIN : in std_logic;
> CLKFB : in std_logic;
> DSSEN : in std_logic;
> PSINCDEC : in std_logic;
> PSEN : in std_logic;
> PSCLK : in std_logic;
> RST : in std_logic;
> CLK0 : out std_logic;
> CLK90 : out std_logic;
> CLK180 : out std_logic;
> CLK270 : out std_logic;
> CLK2X : out std_logic;
> CLK2X180 : out std_logic;
> CLKDV : out std_logic;
> CLKFX : out std_logic;
> CLKFX180 : out std_logic;
> LOCKED : out std_logic;
> PSDONE : out std_logic;
> STATUS : out std_logic_vector(7 downto 0)
> );
> end component;
>
> component RAMB16_S9_S9
> -- synthesis translate_off
> generic (
> WRITE_MODE_A : string;
> WRITE_MODE_B : string;
> INITP_00, INITP_01, INITP_02, INITP_03,
> INITP_04, INITP_05, INITP_06, INITP_07,
> INIT_00, INIT_01, INIT_02, INIT_03,
> INIT_04, INIT_05, INIT_06, INIT_07,
> INIT_08, INIT_09, INIT_0A, INIT_0B,
> INIT_0C, INIT_0D, INIT_0E, INIT_0F,
> INIT_10, INIT_11, INIT_12, INIT_13,
> INIT_14, INIT_15, INIT_16, INIT_17,
> INIT_18, INIT_19, INIT_1A, INIT_1B,
> INIT_1C, INIT_1D, INIT_1E, INIT_1F,
> INIT_20, INIT_21, INIT_22, INIT_23,
> INIT_24, INIT_25, INIT_26, INIT_27,
> INIT_28, INIT_29, INIT_2A, INIT_2B,
> INIT_2C, INIT_2D, INIT_2E, INIT_2F,
> INIT_30, INIT_31, INIT_32, INIT_33,
> INIT_34, INIT_35, INIT_36, INIT_37,
> INIT_38, INIT_39, INIT_3A, INIT_3B,
> INIT_3C, INIT_3D, INIT_3E, INIT_3F : bit_vector :=3D
> X"0000000000000000000000000000000000000000000000000000000000000000"
> );
> -- synthesis translate_on
>
> port (
> DIA : in std_logic_vector(7 downto 0);
> DIPA : in std_logic_vector(0 downto 0);
> DIB : in std_logic_vector(7 downto 0);
> DIPB : in std_logic_vector(0 downto 0);
> ENA : in std_ulogic;
> ENB : in std_ulogic;
> WEA : in std_ulogic;
> WEB : in std_ulogic;
> SSRA : in std_ulogic;
> SSRB : in std_ulogic;
> CLKA : in std_ulogic;
> CLKB : in std_ulogic;
> ADDRA : in std_logic_vector(10 downto 0);
> ADDRB : in std_logic_vector(10 downto 0);
> DOA : out std_logic_vector(7 downto 0);
> DOPA : out std_logic_vector(0 downto 0);
> DOB : out std_logic_vector(7 downto 0);
> DOPB : out std_logic_vector(0 downto 0)
> );
>
> end component;
>
> constant INITP : bit_vector :=3D
> X"1041000100001400010000100040100001400010004100041000100004000104";
> constant INIT : bit_vector :=3D
> X"1001000100001000010000100000100001000010000100001000100001000100";
>
> signal clk_p, clk_n, clk, rst : std_logic;
> signal clk_ibufg, clk_bufg : std_logic;
>
> begin -- architecture sim
>
> INBUF: IBUFGDS_LVPECL_33
> port map (
> O =3D clk_ibufg,
> I =3D clk_p,
> IB =3D clk_n);
>
> GLOBALBUFFER: BUFG
> port map (
> I =3D clk_ibufg,
> O =3D clk_bufg);
>
> clk <=3D clk_bufg;
>
> THERAM: RAMB16_S9_S9
> generic map (
> WRITE_MODE_A =3D "WRITE_FIRST",
> WRITE_MODE_B =3D "READ_FIRST",
> INITP_00 =3D INITP,
> INITP_01 =3D INITP,
> INITP_02 =3D INITP,
> INITP_03 =3D INITP,
> INITP_04 =3D INITP,
> INITP_05 =3D INITP,
> INITP_06 =3D INITP,
> INITP_07 =3D INITP,
> INIT_00 =3D INIT,
> INIT_01 =3D INIT,
> INIT_02 =3D INIT,
> INIT_03 =3D INIT,
> INIT_04 =3D INIT,
> INIT_05 =3D INIT,
> INIT_06 =3D INIT,
> INIT_07 =3D INIT,
> INIT_08 =3D INIT,
> INIT_09 =3D INIT,
> INIT_0A =3D INIT,
> INIT_0B =3D INIT,
> INIT_0C =3D INIT,
> INIT_0D =3D INIT,
> INIT_0E =3D INIT,
> INIT_0F =3D INIT,
> INIT_10 =3D INIT,
> INIT_11 =3D INIT,
> INIT_12 =3D INIT,
> INIT_13 =3D INIT,
> INIT_14 =3D INIT,
> INIT_15 =3D INIT,
> INIT_16 =3D INIT,
> INIT_17 =3D INIT,
> INIT_18 =3D INIT,
> INIT_19 =3D INIT,
> INIT_1A =3D INIT,
> INIT_1B =3D INIT,
> INIT_1C =3D INIT,
> INIT_1D =3D INIT,
> INIT_1E =3D INIT,
> INIT_1F =3D INIT,
> INIT_20 =3D INIT,
> INIT_21 =3D INIT,
> INIT_22 =3D INIT,
> INIT_23 =3D INIT,
> INIT_24 =3D INIT,
> INIT_25 =3D INIT,
> INIT_26 =3D INIT,
> INIT_27 =3D INIT,
> INIT_28 =3D INIT,
> INIT_29 =3D INIT,
> INIT_2A =3D INIT,
> INIT_2B =3D INIT,
> INIT_2C =3D INIT,
> INIT_2D =3D INIT,
> INIT_2E =3D INIT,
> INIT_2F =3D INIT,
> INIT_30 =3D INIT,
> INIT_31 =3D INIT,
> INIT_32 =3D INIT,
> INIT_33 =3D INIT,
> INIT_34 =3D INIT,
> INIT_35 =3D INIT,
> INIT_36 =3D INIT,
> INIT_37 =3D INIT,
> INIT_38 =3D INIT,
> INIT_39 =3D INIT,
> INIT_3A =3D INIT,
> INIT_3B =3D INIT,
> INIT_3C =3D INIT,
> INIT_3D =3D INIT,
> INIT_3E =3D INIT,
> INIT_3F =3D INIT)
> port map (
> DIA =3D "00000000",
> DIPA =3D "0",
> DIB =3D "00000000",
> DIPB =3D "0",
> ENA =3D '1',
> ENB =3D '1',
> WEA =3D '0',
> WEB =3D '0',
> SSRA =3D '0',
> SSRB =3D '0',
> CLKA =3D clk_p,
> CLKB =3D clk,
> ADDRA =3D "00000000000",
> ADDRB =3D "00000000000",
> DOA =3D open,
> DOPA =3D open,
> DOB =3D open,
> DOPB =3D open);
>
> -- CLK process
> process
> begin
> clk_p <=3D '0';
> clk_n <=3D '1';
> loop
> wait for (10 ns);
> clk_p <=3D not clk_p;
> clk_n <=3D not clk_n;
> end loop;
> end process;
>
> MAIN: process
> begin -- process MAIN
>
> rst <=3D '1';
> wait for 10 ns;
> rst <=3D '0';
>
> wait;
>
> end process MAIN;
> end architecture sim;
>
> --
> Patrik Eriksson | patrik.eriksson@netinsight.net
> Net Insight AB | phone: +46 8 685 04 89
> V=E4stberga All=E9 9 | fax: +46 8 685 04 20
> SE-126 30 STOCKHOLM, Sweden | http://www.netinsight.net
Article: 46157Jon, There are many solutions, but to make sure for bidirectional signals, use a level logic shift device like a P82B96 from Philips or other. Laurent http://www.amontec.com Jon Beniston wrote: > Greetings, > > I'm am trying to implement a PS/2 Keyboard interface in a Virtex-E > device. The problem is that the keyboard uses 5V TTL logic whereas the > Virtex-E uses 3.3V LVTTL. What I would like to know is, is it possible > to connect these two directly? According to a Xilinx tech note > (http://www.xilinx.com/products/virtex/techtopic/vtt002.pdf), an input > pad on the Virtex-E is 5V tolerant providing an 100 ohm external > resistor is used. It also says that it can output to a 5V TTL device > providing nothing on the receiving device pulls a signal greater than > 3.6V. However, the data and clock lines for the PS/2 interface are > bi-directional. It seems from this document that the bi-dir IO buffers > aren't 5V tolerant. Also what do I do if the keyboard drives more than > 3.6V? How do I add an external pullup resistor? I'm a complete novice so > a explaination that assumes zero knowlege would be really appreciated! > > Cheers, > JonB > > >Article: 46158
If the timing checks didn't do it, I am pretty sure your BRAM is getting clocked
before the controls are valid. All it takes is one delta cycle. This is why I
recommended starting the simulation with the clock low rather than high, so that
as the simulation starts up the clock goes from 'U' to '0' instead of from 'U' to
1. That way, if there are fewer delta cycle delays on the clock path than on the
controls path you won't have the clock transitioning to '1' before the controls
become othter than 'U'. BTW, If you use the clkdll and drive the BRAM controls
directly from registers, you shouldn't hit this situation (the clk dll has quite a
few delta cycle delay).
Patrik Eriksson wrote:
> Ray Andraka wrote:
>
> > Try setting the TimingChecksOn generic to false. I've had troubles in the
> > past when that is in the (default) on state interfacing with RTL designs.
>
> I tried that with the same result.
>
> > Also, you may be bringing the clock high at the same time you are bringing
> > the WE to inactive at the very beginning of your sim. Try starting with the
> > clock low.
>
> I think that the simulation model is incorrect. It is not true dual port
> and the behaviour is wrong.
>
> I've got this from xilinx support:
>
> -----------
> I have just found the following internal solution.
>
> Keywords: unisim, functional, simulation, RAMB4_Sm_Sn, RAMB16_Sm_Sn
>
> Urgency: Standard
>
> Description: When performing a functional (behavioral) simulation on a
> RAMB16_S9_S9 the following error message may be seen after issuing the
> vsim (load design) command:
> # ** Warning: Invalid ADDRESS: XXXXXXXXXXX. Memory contents will be set
> to 'X'.
>
> The simulation procedes but as suggested by the warning, the memory
> contents are not initialised to correct values.
>
> The warning occured because only one of the clock inputs to the dual
> port RAM had passed through an IBUFG. The following workarounds will
> cure the problem:
> 1) Ensure that both clocks do NOT have an IBUFG directly instantiated in
> the code. IBUFGs will be inferred automatically if the default project
> options are set.
> OR
> 2) Ensure that both clocks have an IBUFG.
>
> ------------
>
> Solution 2 solved my problem in the simple test code but not my real
> design. I have to investigate it further.
>
> Thanks!
>
> Patrik
>
> >
> > Patrik Eriksson wrote:
> >
> >
> >>When I simulates the following code this warning message is displayed at
> >>time 0ns.
> >>
> >># ** Warning: Invalid ADDRESS: XXXXXXXXXX. Memory contents will be set
> >>to 'X'.
> >># Time: 0 ps Iteration: 3 Instance: /theram
> >>
> >>This means that I can't simulate with correct INIT values!!
> >>All addresses and control signals are constant but the clock inputs are
> >>toggled.
> >>
> >>Have I done anything stupid? Is there an error in the simulation model?
> >>This code is a debug version of my real design just to track the
> >>simulation error.
> >>
> >>I thought that if WEx is de-asserted nothing should happen to the memory
> >>contents whatever the other signals looks like.
> >>
> >>/Patrik Eriksson
> >>-----------
> >>
> >>library ieee;
> >> use ieee.std_logic_1164.all;
> >> use ieee.std_logic_unsigned.all;
> >>
> >> -- synthesis translate_off
> >> library unisim;
> >> -- synthesis translate_on
> >>
> >> entity bram_tb is
> >>
> >> end entity bram_tb;
> >>
> >> architecture sim of bram_tb is
> >>
> >> component BUFG
> >> port (
> >> I : in std_logic;
> >> O : out std_logic);
> >> end component;
> >>
> >> component IBUFGDS_LVPECL_33
> >> port (
> >> O : out std_ulogic;
> >> I : in std_ulogic;
> >> IB : in std_ulogic);
> >> end component;
> >>
> >> component DCM
> >> -- synthesis translate_off
> >> generic (
> >> DLL_FREQUENCY_MODE : string := "LOW";
> >> CLKOUT_PHASE_SHIFT : string := "NONE";
> >> PHASE_SHIFT : integer := 0;
> >> CLKFX_MULTIPLY : integer := 4;
> >> CLKDV_DIVIDE : real := 2.0
> >> );
> >> -- synthesis translate_on
> >> port (
> >> CLKIN : in std_logic;
> >> CLKFB : in std_logic;
> >> DSSEN : in std_logic;
> >> PSINCDEC : in std_logic;
> >> PSEN : in std_logic;
> >> PSCLK : in std_logic;
> >> RST : in std_logic;
> >> CLK0 : out std_logic;
> >> CLK90 : out std_logic;
> >> CLK180 : out std_logic;
> >> CLK270 : out std_logic;
> >> CLK2X : out std_logic;
> >> CLK2X180 : out std_logic;
> >> CLKDV : out std_logic;
> >> CLKFX : out std_logic;
> >> CLKFX180 : out std_logic;
> >> LOCKED : out std_logic;
> >> PSDONE : out std_logic;
> >> STATUS : out std_logic_vector(7 downto 0)
> >> );
> >> end component;
> >>
> >> component RAMB16_S9_S9
> >> -- synthesis translate_off
> >> generic (
> >> WRITE_MODE_A : string;
> >> WRITE_MODE_B : string;
> >> INITP_00, INITP_01, INITP_02, INITP_03,
> >> INITP_04, INITP_05, INITP_06, INITP_07,
> >> INIT_00, INIT_01, INIT_02, INIT_03,
> >> INIT_04, INIT_05, INIT_06, INIT_07,
> >> INIT_08, INIT_09, INIT_0A, INIT_0B,
> >> INIT_0C, INIT_0D, INIT_0E, INIT_0F,
> >> INIT_10, INIT_11, INIT_12, INIT_13,
> >> INIT_14, INIT_15, INIT_16, INIT_17,
> >> INIT_18, INIT_19, INIT_1A, INIT_1B,
> >> INIT_1C, INIT_1D, INIT_1E, INIT_1F,
> >> INIT_20, INIT_21, INIT_22, INIT_23,
> >> INIT_24, INIT_25, INIT_26, INIT_27,
> >> INIT_28, INIT_29, INIT_2A, INIT_2B,
> >> INIT_2C, INIT_2D, INIT_2E, INIT_2F,
> >> INIT_30, INIT_31, INIT_32, INIT_33,
> >> INIT_34, INIT_35, INIT_36, INIT_37,
> >> INIT_38, INIT_39, INIT_3A, INIT_3B,
> >> INIT_3C, INIT_3D, INIT_3E, INIT_3F : bit_vector :=
> >> X"0000000000000000000000000000000000000000000000000000000000000000"
> >> );
> >> -- synthesis translate_on
> >>
> >> port (
> >> DIA : in std_logic_vector(7 downto 0);
> >> DIPA : in std_logic_vector(0 downto 0);
> >> DIB : in std_logic_vector(7 downto 0);
> >> DIPB : in std_logic_vector(0 downto 0);
> >> ENA : in std_ulogic;
> >> ENB : in std_ulogic;
> >> WEA : in std_ulogic;
> >> WEB : in std_ulogic;
> >> SSRA : in std_ulogic;
> >> SSRB : in std_ulogic;
> >> CLKA : in std_ulogic;
> >> CLKB : in std_ulogic;
> >> ADDRA : in std_logic_vector(10 downto 0);
> >> ADDRB : in std_logic_vector(10 downto 0);
> >> DOA : out std_logic_vector(7 downto 0);
> >> DOPA : out std_logic_vector(0 downto 0);
> >> DOB : out std_logic_vector(7 downto 0);
> >> DOPB : out std_logic_vector(0 downto 0)
> >> );
> >>
> >> end component;
> >>
> >> constant INITP : bit_vector :=
> >>X"1041000100001400010000100040100001400010004100041000100004000104";
> >> constant INIT : bit_vector :=
> >>X"1001000100001000010000100000100001000010000100001000100001000100";
> >>
> >> signal clk_p, clk_n, clk, rst : std_logic;
> >> signal clk_ibufg, clk_bufg : std_logic;
> >>
> >> begin -- architecture sim
> >>
> >> INBUF: IBUFGDS_LVPECL_33
> >> port map (
> >> O = clk_ibufg,
> >> I = clk_p,
> >> IB = clk_n);
> >>
> >> GLOBALBUFFER: BUFG
> >> port map (
> >> I = clk_ibufg,
> >> O = clk_bufg);
> >>
> >> clk <= clk_bufg;
> >>
> >> THERAM: RAMB16_S9_S9
> >> generic map (
> >> WRITE_MODE_A = "WRITE_FIRST",
> >> WRITE_MODE_B = "READ_FIRST",
> >> INITP_00 = INITP,
> >> INITP_01 = INITP,
> >> INITP_02 = INITP,
> >> INITP_03 = INITP,
> >> INITP_04 = INITP,
> >> INITP_05 = INITP,
> >> INITP_06 = INITP,
> >> INITP_07 = INITP,
> >> INIT_00 = INIT,
> >> INIT_01 = INIT,
> >> INIT_02 = INIT,
> >> INIT_03 = INIT,
> >> INIT_04 = INIT,
> >> INIT_05 = INIT,
> >> INIT_06 = INIT,
> >> INIT_07 = INIT,
> >> INIT_08 = INIT,
> >> INIT_09 = INIT,
> >> INIT_0A = INIT,
> >> INIT_0B = INIT,
> >> INIT_0C = INIT,
> >> INIT_0D = INIT,
> >> INIT_0E = INIT,
> >> INIT_0F = INIT,
> >> INIT_10 = INIT,
> >> INIT_11 = INIT,
> >> INIT_12 = INIT,
> >> INIT_13 = INIT,
> >> INIT_14 = INIT,
> >> INIT_15 = INIT,
> >> INIT_16 = INIT,
> >> INIT_17 = INIT,
> >> INIT_18 = INIT,
> >> INIT_19 = INIT,
> >> INIT_1A = INIT,
> >> INIT_1B = INIT,
> >> INIT_1C = INIT,
> >> INIT_1D = INIT,
> >> INIT_1E = INIT,
> >> INIT_1F = INIT,
> >> INIT_20 = INIT,
> >> INIT_21 = INIT,
> >> INIT_22 = INIT,
> >> INIT_23 = INIT,
> >> INIT_24 = INIT,
> >> INIT_25 = INIT,
> >> INIT_26 = INIT,
> >> INIT_27 = INIT,
> >> INIT_28 = INIT,
> >> INIT_29 = INIT,
> >> INIT_2A = INIT,
> >> INIT_2B = INIT,
> >> INIT_2C = INIT,
> >> INIT_2D = INIT,
> >> INIT_2E = INIT,
> >> INIT_2F = INIT,
> >> INIT_30 = INIT,
> >> INIT_31 = INIT,
> >> INIT_32 = INIT,
> >> INIT_33 = INIT,
> >> INIT_34 = INIT,
> >> INIT_35 = INIT,
> >> INIT_36 = INIT,
> >> INIT_37 = INIT,
> >> INIT_38 = INIT,
> >> INIT_39 = INIT,
> >> INIT_3A = INIT,
> >> INIT_3B = INIT,
> >> INIT_3C = INIT,
> >> INIT_3D = INIT,
> >> INIT_3E = INIT,
> >> INIT_3F = INIT)
> >> port map (
> >> DIA = "00000000",
> >> DIPA = "0",
> >> DIB = "00000000",
> >> DIPB = "0",
> >> ENA = '1',
> >> ENB = '1',
> >> WEA = '0',
> >> WEB = '0',
> >> SSRA = '0',
> >> SSRB = '0',
> >> CLKA = clk_p,
> >> CLKB = clk,
> >> ADDRA = "00000000000",
> >> ADDRB = "00000000000",
> >> DOA = open,
> >> DOPA = open,
> >> DOB = open,
> >> DOPB = open);
> >>
> >> -- CLK process
> >> process
> >> begin
> >> clk_p <= '0';
> >> clk_n <= '1';
> >> loop
> >> wait for (10 ns);
> >> clk_p <= not clk_p;
> >> clk_n <= not clk_n;
> >> end loop;
> >> end process;
> >>
> >> MAIN: process
> >> begin -- process MAIN
> >>
> >> rst <= '1';
> >> wait for 10 ns;
> >> rst <= '0';
> >>
> >> wait;
> >>
> >> end process MAIN;
> >> end architecture sim;
> >>
> >>--
> >>Patrik Eriksson | patrik.eriksson@netinsight.net
> >>Net Insight AB | phone: +46 8 685 04 89
> >>Västberga Allé 9 | fax: +46 8 685 04 20
> >>SE-126 30 STOCKHOLM, Sweden | http://www.netinsight.net
> >>
> >
> > --
> > --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
> >
> >
> >
>
> --
> Patrik Eriksson | patrik.eriksson@netinsight.net
> Net Insight AB | phone: +46 8 685 04 89
> Västberga Allé 9 | fax: +46 8 685 04 20
> SE-126 30 STOCKHOLM, Sweden | http://www.netinsight.net
--
--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: 46159
Wind River presents:
Virtex II PRO Tutorial:
"The Xilinx Virtex II PRO PowerPC 405 Architecture Familiarization"
Wind River is pleased to provide our FREE 1/2 day tutorial: "The Xilinx
Virtex II PRO - PowerPC 405 Architecture Familiarization," including a
special development tools demonstration. We are confident you will find them
very productive for engineers who are designing and developing embedded
systems. The Xilinx Virtex II PRO - PowerPC 405 Familiarization Tutorial is
intended for those who have selected or are close to selecting the Xilinx
Virtex II PRO for a project.
SCHEDULE & LOCATION
When: Sept. 4th, 2002
Time: 8:00 am - 12:00 pm
Where: Ottawa Marriott
100 Kent St.
Ottawa, ON K1P 5R7
Ph: (613) 783-4215
AGENDA
08:00 - 09:00 Registration - Coffee & Pastries
09:00 - 12:00 Virtex II PRO - PowerPC405 Tutorial
HOW TO REGISTER
Fax - Email:
SAT/HAT Training
Wind River
Fax: (781) 364-2020
Email: dtgtraining@windriver.com
Seating is limited, so Please fax form or email us with the following
information:
Name:
Company:
Address:
City, State ZIP:
Phone #:
Email Address:
Article: 46160Hi, guys Is there any detailed documenation about XDL format online, I am trying to see whether it's possible to transfer my design format to XDL format. Thanks! WeifengArticle: 46161
I need to use some Xilinx primitives in my VHDL, and they seem to be in different libraries for use with ModelSim and Synplify. Here's what I have so far... library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; -- synthesis translate_off library unisim; use unisim.all; -- synthesis translate_on library virtex; use virtex.components.all; ... This works fine in Synplify, but for ModelSim I have to comment out the two lines... --library virtex; --use virtex.components.all; Does anyone know a better way to "hide" these from ModelSim? Thanks, Barry BrownArticle: 46162
> It would be decidedly more fun if it didn't use an obsolete SpartanXL > part that is not supported by WebPack. > I have a new Xport sitting on my desk and it seems pretty handy. The choice of FPGA is somewhat painful but I can understand why it was chosen based on other parts of the system, ie available voltage and power requirements. The choice of FPGA would probably not cause any problems for a lab environment where a teacher/professor provided the bitstream and assigned a C/C++/asm programming task to students. The Xport would be a great tool for teaching embedded programming. Anyway, I'm teaching myself Verilog and now need to synthesize a simple design and map it to the SpartanXL in this device. My design had been simulated using Icarus Verilog and was basically ready to go, but then I went to create a project in WebPack and found that the FPGA was not supported. Oh, that ruined my evening. Does anyone have a suggestion for an inexpensive tool that I can use? I hear the old student version Foundation 2.1 tools have the compiler etc but I'm worried that Xilinx will no longer issue a license. Does this old tool have node locked (to ethernet ID) licenses that need to be issued by Xilinx? -Jonathan O'BrienArticle: 46163
Do a search for xdl in the Xilinx directory. You can do anything you want in the Xilinx Design Language (xdl). Steve "Weifeng Xu" <wxu@ecs.umass.edu> wrote in message news:3D6272B3.F01E5EB5@ecs.umass.edu... > Hi, guys > Is there any detailed documenation about XDL format online, I am > trying to see whether it's possible to transfer my design format to XDL > format. > Thanks! > > Weifeng >Article: 46164
you don't need those two lines for synplify either. Just leave them out.
Barry Brown wrote:
> I need to use some Xilinx primitives in my VHDL, and they seem to be in
> different libraries for use with ModelSim and Synplify. Here's what I have
> so far...
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_unsigned.all;
> -- synthesis translate_off
> library unisim;
> use unisim.all;
> -- synthesis translate_on
> library virtex;
> use virtex.components.all;
> ...
>
> This works fine in Synplify, but for ModelSim I have to comment out the two
> lines...
>
> --library virtex;
> --use virtex.components.all;
>
> Does anyone know a better way to "hide" these from ModelSim?
>
> Thanks,
> Barry Brown
--
--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: 46165
It sounds like the job market is really bad when you start
seeing resumes being posted at comp.arch.fpga.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 46166Hi, we have an older product that uses Actel 1280XL-TQ176 chips, and one chip has a horrible, basicly-impossible-to-explain bug [1]. Since these critters are OTP, we may well wind up replacing the chip several times before we get it fixed, so we'd like to use a socket, butchered into the regular PCB footprint somehow. So, does anybody know of a source for such a socket? We've found the Yamaichi parts, which solder directly to the chip layout, but delivery is 10 weeks or somesuch and min order is 10 pieces at $80 each. If anybody has any extras around (like, *you* had to buy 10) we'd be pleased to purchase a few. And yes, we use Xilinx now; this resulted from a chance encounter with Peter Alfke as we simultaneously attacked a box of goodies on the ground at the Foothill Electronic Flea Market. John [1] We load a down-counter in an idle state, using the system clock; later we count down using a different clock. The logic looks OK, but one narrow range of presets loads wrong.Article: 46167
schachinger@decomsys.com (Schachinger Martin) wrote in message news:<7b75b7ff.0208200538.4ce7f867@posting.google.com>... > I have a problem with the JAM STAPL Player Version 2.2. > But first i summarize what i have done so far: > > When i program the devices with the MAX2PLUS Programmer under Windows > with the same JAM-File it works all the time. > So i think there is a bug in the JAM STAPL Player. > Do you understand my problem? Have you an Idea what's going wrong with > the player, or where i can look to trace the error? > Because i need the JAM Player under LINUX and it is nessesary that it > works ALL the time and not every now and then. > > I hope you can help me with this problem... > have a nice day > > yours > Schachinger Martin > schachinger@decomsys.com > VIENNA - AUSTRIA Since JAM sometimes works, and it always works under MAXPLUS, it sounds like a timing problem. How did you program the timing loop? I believe this is something you need to port because every target is different. You might try slowing down the timing loop by half to see if it works any better. Alan Nishioka alann@accom.comArticle: 46168
On Tue, 20 Aug 2002 14:22:19 -0000, hmurray@suespammers.org (Hal Murray) wrote: >>Whether you really care about the initial state is dependent on your >>application. I find that most of my designs are tolerant to wrong >>initial states, so I don't bother doing anything about it. > >I got an "interesting" education on that topic many years ago. > >I had a simple one-hot state machine with 4 states. Just a single bit >running around in a circle. One FF was inverted so that 0000 was a >valid state and reset would start right. How simple can something be? > >It had a bug. The GSR signal hit one CLB before the other. It ended >up with 2 bits running around. > >I've been more careful/paranoid since. It may not take any more >code/logic, but it does take more thought. > >That bug was just a simple setup/hold problem. If you want to get >serious, consider metastability. I should have said that most of my designs are tolerant to wrong initial states *because I design them that way*. A beginner is likely to miss potential hangups, and a synchronous reset is a reasonably reliable way of avoiding the problem. I am aware that synthesis tools can take my perfectly correct and safe FSM and "optimise" it into something that isn't safe (e.g. binary to one-hot trancoding). This hasn't bitten me ... yet. Regards, Allan.Article: 46169
Has anyone been able to successfully use the free Xilinx QDR Controller that's described in App Note #262? I downloaded it, ran a Verilog sim, and it doesn't look like it is functioning correctly. Just looking at the writes, the address given to the controller is not the address that the controller sends out the QDR.Article: 46170
Hi All, Xilinx recommends LVPECL inputs to Virtex-II be terminated with a 100ohm resistor between the LVPECL input differential pair. I wish to terminate my LVPECL inputs with 50ohms to VTT (where VTT = VCCO - 2V) on each leg of the differential pair at the Virtex-II chip end. Has anyone successfully used this LVPECL termination on Virtex-II chips ? Thanks. KheeArticle: 46171
You might enjoy our Altera tutorial (we also have Xilinx material) http://tutor.al-williams.com. Mostly schematic entry but some Verilog stuff also. Al Williams AWC people@micro-web.co.kr (JinSoo Kim) wrote in message news:<edc45795.0208192147.d2d841b@posting.google.com>... > Hello, > > I am a beginner in CPLD and have a difficulty in reading CPLD datasheet. > (Altera's MAX3000 CPLD). > It describes the hardware architecture of CPLD. > Macrocells, Logic array block, Expander product terms, Programmable > interconnect array... > They are unfamiliar to me so it is hard to read the datasheet. > Is there a good documentation or book which discusses more basic concepts > about CPLD hardware architecture? > > Thanks in advance... :-)Article: 46172
On Mon, 19 Aug 2002 15:35:58 GMT, Patrik Eriksson <patrik.eriksson@netinsight.net> wrote: >When I simulates the following code this warning message is displayed at >time 0ns. > ># ** Warning: Invalid ADDRESS: XXXXXXXXXX. Memory contents will be set >to 'X'. ># Time: 0 ps Iteration: 3 Instance: /theram I just found that this feature was recently introduced with the unisim_vcomp.vhd that shipped with a recent service pack of 4.2i. I had a test bench that had been working fine, and I recently recompiled my copy of unisim_vcomp (using the SP3 source) and my testbench stopped working :( I had the clocks starting at '1', and Ray's suggested fix of having them start at '0' made the problem go away. (Thanks Ray.) This points to a bug in the unisim library. I feel that the rambx components should not see an initial clock of '1' as a rising edge. Regards, Allan.Article: 46173
I have seen this happen before in non-Xilinx stuff as well. The problem is
the if clk'event and clk='1' (which is what rising_edge(clk) does too), looks
for an event on the clock and a current value of '1', so any transition that
ends in a '1' is going to be interpreted as a clock rising edge by the sim,
and that includes the initial transition from 'U' to '1'. If the delta
delays in your particular model are such that the clock has more delta delays
than the data, you are fine. If not, then you have a problem. It just so
happens that the old BRAM model had an additional delay into the clock
relative to the data inside the model that is no longer there. I don't think
that this is a xilinx bug per se, although it could certainly be eliminated
by putting initial values or on the data path or extra delta delays
(connecting to local clock signal names) inside the model.
As I said, this is certainly not unique to xilinx, and you are probably
fortunate not to have run into it before.
Allan Herriman wrote:
> On Mon, 19 Aug 2002 15:35:58 GMT, Patrik Eriksson
> <patrik.eriksson@netinsight.net> wrote:
>
> >When I simulates the following code this warning message is displayed at
> >time 0ns.
> >
> ># ** Warning: Invalid ADDRESS: XXXXXXXXXX. Memory contents will be set
> >to 'X'.
> ># Time: 0 ps Iteration: 3 Instance: /theram
>
> I just found that this feature was recently introduced with the
> unisim_vcomp.vhd that shipped with a recent service pack of 4.2i.
>
> I had a test bench that had been working fine, and I recently
> recompiled my copy of unisim_vcomp (using the SP3 source) and my
> testbench stopped working :(
>
> I had the clocks starting at '1', and Ray's suggested fix of having
> them start at '0' made the problem go away. (Thanks Ray.)
>
> This points to a bug in the unisim library. I feel that the rambx
> components should not see an initial clock of '1' as a rising edge.
>
> Regards,
> Allan.
--
--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: 46174http://www.clear-logic.com/
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