Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I am doing a project for a Virtex2 fpga with the Free ISE WebPACK 5.2i with
all the latest patches. I am writing a piece of behavioral VHDL that will
synthesize as dual ported block ram and a testbench to verify its behavior
by writing three values to it and then read them back. This works all fine
in a behavioral simulation, but when I advance to a post-translate or
post-place & route simulation the last of the three values read ( the first
written) is wrong. Can someone tell me what is wrong? Maybe it is never
written?
I have also tried to instantiate the block ram manualy (RAMB1_s36_s36). This
gives exactly the same problem.
Sincerely Christian.
This is my VHDL
----Memory.vhd------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity memory is
Port ( clk : in std_logic;
reset : in std_logic;
write_addr : in std_logic_vector(8 downto 0);
write_data : in std_logic_vector(31 downto 0);
write_en : in std_logic;
read_addr : in std_logic_vector(8 downto 0);
read_data : out std_logic_vector(31 downto 0);
read_en : in std_logic);
end memory;
architecture Behavioral of memory is
type mem_type is array (511 downto 0) of std_logic_vector(31 downto 0);
signal data : mem_type := (OTHERS => (OTHERS => '0'));
begin
process (clk)
begin
IF clk'event AND clk = '1' then
if write_en = '1' then
data(CONV_INTEGER(UNSIGNED(write_addr))) <= write_data;
end if;
IF read_en = '1' THEN
read_data <= data(CONV_INTEGER(UNSIGNED(read_addr)));
END IF;
end if;
end process;
end Behavioral;
-------------------------
--Testbench----------------------
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;
ENTITY testbench IS
END testbench;
ARCHITECTURE behavior OF testbench IS
COMPONENT memory
PORT(
clk : IN std_logic;
reset : IN std_logic;
write_addr : IN std_logic_vector(8 downto 0);
write_data : IN std_logic_vector(31 downto 0);
write_en : IN std_logic;
read_addr : IN std_logic_vector(8 downto 0);
read_data : OUT std_logic_vector(31 downto 0);
read_en : in std_logic
);
END COMPONENT;
SIGNAL clk : std_logic;
SIGNAL reset : std_logic;
SIGNAL write_addr : std_logic_vector(8 downto 0);
SIGNAL write_data : std_logic_vector(31 downto 0);
SIGNAL write_en : std_logic;
SIGNAL read_addr : std_logic_vector(8 downto 0);
SIGNAL read_data : std_logic_vector(31 downto 0);
SIGNAL read_en : std_logic;
BEGIN
uut: memory PORT MAP(
clk => clk,
reset => reset,
write_addr => write_addr,
write_data => write_data,
write_en => write_en,
read_addr => read_addr,
read_data => read_data,
read_en => read_en
);
PROCESS
BEGIN
clk <= '0';
wait for 50 ns;
clk <= '1';
wait for 50 ns;
END PROCESS;
reset <= '1', '0' after 7 ns;
read_en <= '1';
read_addr <= "100000000", "000100001" after 107 ns, "001000010" after 207
ns, "000000000" after 307 ns, "000000001" after 407 ns, "000000010" after
507 ns;
write_addr <= "000000010", "000000001" after 107 ns, "000000000" after 207
ns, "010000000" after 307 ns, "000010001" after 407 ns, "000001010" after
507 ns;
write_data <= X"00000003", X"00000002" after 107 ns, X"00000001" after 207
ns;
write_en <= '1', '0' after 307 ns;
END;
-------------------------------------------
Article: 58976Christian Obel wrote: > I am doing a project for a Virtex2 fpga with the Free ISE WebPACK 5.2i with > all the latest patches. I am writing a piece of behavioral VHDL that will > synthesize as dual ported block ram and a testbench to verify its behavior > by writing three values to it and then read them back. This works all fine > in a behavioral simulation, but when I advance to a post-translate or > post-place & route simulation the last of the three values read ( the first > written) is wrong. Can someone tell me what is wrong? Maybe it is never > written? Maybe you need to register the address. http://groups.google.com/groups?q=sync_ram+entity+lpm_ram_dq -- Mike TreselerArticle: 58977
io@duke.edu wrote: > Hi - > > I am trying to run a very simple simulation to verify the functionality of > the "block ram" component in my spartan ii fpga. I am using modelsim > tools that I downloaded from the xilinx website, and I'm using the > "ramb4_s8" primitive. The simulation appears to work properly except that > there appears to be a delay of one clock cycle when reading from the > memory. In other words, if I enable the ram, deassert the write enable, > and select the read address, I need TWO rising clock edges to get the > correct data to appear at the data_out port. I am doing a simple > behavioral simulation so there shouldn't be any delay issues involved. > The data sheet clearly shows that I should only need one rising clock edge > to execute the read. Any ideas? Thanks very much!!! > > --Iyad > > ------------------------------- > Iyad Obeid > Dept. of Biomedical Engineering > Duke University > io@duke.edu > (919)660-5104 www.duke.edu/~io Maybe you need to register the address. http://groups.google.com/groups?q=sync_ram+entity+lpm_ram_dq -- Mike TreselerArticle: 58978
Have you tried AHDL 6.1 service pack 1? Though using it with Altera (cos I have to) there are various fixes to bits and pieces. YMMV "Jay" <yuhaiwen@hotmail.com> wrote in message news:bgnoeu$qa34o$1@ID-195883.news.uni-berlin.de... > When both of them were installed on my pc, I found: > 1.ModelSim can't compile Xilinx library > 2.ISE will give a fatal error when ActiveHDL try generate post-PAR timing > simulation model > > and they both can work well separately. > >Article: 58979
Peter Ryser wrote: > Linux support for Virtex-II Pro is available as part of the LinuxPPC kernel > tree. Access to this tree which is synchronized with the main kernel tree in > regular intervals is available from http://www.penguinppc.org/kernel.shtml. > MontaVista is just one host for the tree. I know as I have several different (in fact more than several now) trees. The setup I have is mostly from the Mind patches to the Montavista tree manually applied to 2.4.20 by me because I prefer the kernel.org one without all the additional board support I do not need. > Unfortunately, the code available in the LinuxPPC repository has not > yet been moved into the main kernel tree. I had a discussion with some people recently about that. The thing is that there are so many different sources for PowerPC Linux. I use yet another set of patches for my Powerbook which also runs Linux from the benh tree. Jon.Article: 58980
Peter Ryser wrote: > Jon, > > besides what John has produced for uCLinux, Xilinx is working with > MontaVista to integrate UartLite support into the Linux kernel tree for > PowerPC. Any ideas when this will be available? At the moment I have stuck the driver John wrote in to 2.4.20 and changed most of the relevent parts. The plan is to assist debug what he has unless Xilinx and Montavista are likely to have a driver out within the next week or two. Jon.Article: 58981
My apologies if it is too obvious, but did you count the clock cycle that sets up the read address as one of the TWO clock cycles? If you can post your code or waveform, that would be helpful. Jim Wu jimwu88NOOOOOSPAM@yahoo.com io@duke.edu wrote in message news:<Pine.GSO.4.56.0308051041170.29999@hudson11.acpub.duke.edu>... > Hi - > > I am trying to run a very simple simulation to verify the functionality of > the "block ram" component in my spartan ii fpga. I am using modelsim > tools that I downloaded from the xilinx website, and I'm using the > "ramb4_s8" primitive. The simulation appears to work properly except that > there appears to be a delay of one clock cycle when reading from the > memory. In other words, if I enable the ram, deassert the write enable, > and select the read address, I need TWO rising clock edges to get the > correct data to appear at the data_out port. I am doing a simple > behavioral simulation so there shouldn't be any delay issues involved. > The data sheet clearly shows that I should only need one rising clock edge > to execute the read. Any ideas? Thanks very much!!! > > --Iyad > > ------------------------------- > Iyad Obeid > Dept. of Biomedical Engineering > Duke University > io@duke.edu > (919)660-5104 www.duke.edu/~ioArticle: 58982
I really hope (we are working on it) that at some point in time Virtex-II Pro will become part of the main kernel tree. Until then penguinppc is the place to go to for the open source kernel support for V2P. Alternatively, especially for commercial purposes, I recommend to contact MontaVista for professional support. The reason why I suggest to use penguinppc or MontaVista is the tight integration into EDK. EDK is able to generate a board support package, i.e. layer 0 and 1 drivers, tailored for the use within Linux. Parameters like base address, high address, optimizations, and available functions for a given peripheral are automatically copied from the hardware description into the Linux kernel. The same is true for the latest drivers shipping with EDK which update the sources in the kernel tree. - Peter Jon Masters wrote: > Peter Ryser wrote: > > > Linux support for Virtex-II Pro is available as part of the LinuxPPC kernel > > tree. Access to this tree which is synchronized with the main kernel tree in > > regular intervals is available from http://www.penguinppc.org/kernel.shtml. > > MontaVista is just one host for the tree. > > I know as I have several different (in fact more than several now) > trees. The setup I have is mostly from the Mind patches to the > Montavista tree manually applied to 2.4.20 by me because I prefer the > kernel.org one without all the additional board support I do not need. > > > Unfortunately, the code available in the LinuxPPC repository has not > > yet been moved into the main kernel tree. > > I had a discussion with some people recently about that. > The thing is that there are so many different sources for PowerPC Linux. > I use yet another set of patches for my Powerbook which also runs Linux > from the benh tree. > > Jon.Article: 58983
It will probably take more than two weeks. One reason is the OCP support in the open source kernel being broken at the moment (or at least the last time I checked). - Peter Jon Masters wrote: > Peter Ryser wrote: > > Jon, > > > > besides what John has produced for uCLinux, Xilinx is working with > > MontaVista to integrate UartLite support into the Linux kernel tree for > > PowerPC. > > Any ideas when this will be available? At the moment I have stuck the > driver John wrote in to 2.4.20 and changed most of the relevent parts. > The plan is to assist debug what he has unless Xilinx and Montavista are > likely to have a driver out within the next week or two. > > Jon.Article: 58984
Virtex BlockRAMs always register the address internally, even during a read access. (Which is sometimes desirable, sometimes not). Peter Alfke Mike Treseler wrote: > > Christian Obel wrote: > > I am doing a project for a Virtex2 fpga with the Free ISE WebPACK 5.2i with > > all the latest patches. I am writing a piece of behavioral VHDL that will > > synthesize as dual ported block ram and a testbench to verify its behavior > > by writing three values to it and then read them back. This works all fine > > in a behavioral simulation, but when I advance to a post-translate or > > post-place & route simulation the last of the three values read ( the first > > written) is wrong. Can someone tell me what is wrong? Maybe it is never > > written? > > Maybe you need to register the address. > http://groups.google.com/groups?q=sync_ram+entity+lpm_ram_dq > > -- Mike TreselerArticle: 58985
In Virtex BlockRAMs nothing happens without being instigated by a clock edge. That's why they are called synchronous RAMs. Peter Alfke Jim Wu wrote: > > My apologies if it is too obvious, but did you count the clock cycle > that sets up the read address as one of the TWO clock cycles? > > If you can post your code or waveform, that would be helpful. > > Jim Wu > jimwu88NOOOOOSPAM@yahoo.com > > io@duke.edu wrote in message news:<Pine.GSO.4.56.0308051041170.29999@hudson11.acpub.duke.edu>... > > Hi - > > > > I am trying to run a very simple simulation to verify the functionality of > > the "block ram" component in my spartan ii fpga. I am using modelsim > > tools that I downloaded from the xilinx website, and I'm using the > > "ramb4_s8" primitive. The simulation appears to work properly except that > > there appears to be a delay of one clock cycle when reading from the > > memory. In other words, if I enable the ram, deassert the write enable, > > and select the read address, I need TWO rising clock edges to get the > > correct data to appear at the data_out port. I am doing a simple > > behavioral simulation so there shouldn't be any delay issues involved. > > The data sheet clearly shows that I should only need one rising clock edge > > to execute the read. Any ideas? Thanks very much!!! > > > > --Iyad > > > > ------------------------------- > > Iyad Obeid > > Dept. of Biomedical Engineering > > Duke University > > io@duke.edu > > (919)660-5104 www.duke.edu/~ioArticle: 58986
I assert the read address on the falling edge of the clock. On the first
rising edge that follows, I expect to see the data stored at that read
address, but instead i have to wait for the second rising clk edge to see
it.
The vhdl code is below. The waveforms are at www.duke.edu/~io/wave.jpg
Thank you!
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use work.constants.all;
library UNISIM;
use UNISIM.VCOMPONENTS.all;
entity ramtest is
port (
we : in std_logic;
en : in std_logic;
rst : in std_logic;
clk : in std_logic;
addr : in std_logic_vector(8 downto 0);
di : in std_logic_vector(7 downto 0);
do : out std_logic_vector(7 downto 0));
end ramtest;
architecture xilinx of ramtest is
component RAMB4_S8
port (
WE : IN STD_LOGIC;
EN : IN STD_LOGIC;
RST : IN STD_LOGIC;
CLK : IN STD_LOGIC;
ADDR : IN STD_LOGIC_VECTOR(8 DOWNTO 0);
DI : IN STD_LOGIC_VECTOR(7 DOWNTO 0);
DO : OUT STD_LOGIC_VECTOR(7 DOWNTO 0));
end component;
begin -- xilinx
R0 : RAMB4_S8 port map (
WE => we,
EN => en,
RST => rst,
CLK => clk,
ADDR => addr,
DI => di,
DO => do);
end xilinx;
On Tue, 5 Aug 2003, Jim Wu wrote:
> My apologies if it is too obvious, but did you count the clock cycle
> that sets up the read address as one of the TWO clock cycles?
>
> If you can post your code or waveform, that would be helpful.
>
> Jim Wu
> jimwu88NOOOOOSPAM@yahoo.com
>
> io@duke.edu wrote in message news:<Pine.GSO.4.56.0308051041170.29999@hudson11.acpub.duke.edu>...
> > Hi -
> >
> > I am trying to run a very simple simulation to verify the functionality of
> > the "block ram" component in my spartan ii fpga. I am using modelsim
> > tools that I downloaded from the xilinx website, and I'm using the
> > "ramb4_s8" primitive. The simulation appears to work properly except that
> > there appears to be a delay of one clock cycle when reading from the
> > memory. In other words, if I enable the ram, deassert the write enable,
> > and select the read address, I need TWO rising clock edges to get the
> > correct data to appear at the data_out port. I am doing a simple
> > behavioral simulation so there shouldn't be any delay issues involved.
> > The data sheet clearly shows that I should only need one rising clock edge
> > to execute the read. Any ideas? Thanks very much!!!
> >
> > --Iyad
> >
> > -------------------------------
> > Iyad Obeid
> > Dept. of Biomedical Engineering
> > Duke University
> > io@duke.edu
> > (919)660-5104 www.duke.edu/~io
>
-------------------------------
Iyad Obeid
Dept. of Biomedical Engineering
Duke University
io@duke.edu
(919)660-5104 www.duke.edu/~io
Article: 58987Thanks, found it. That looks like exactly the thing. Now where did I put that breadboard ... Rob Andrew Paule wrote: > > The HC part on the schematic is supplied with VCC from your board - you > can also get parts with dual voltage supply that allow this type of > interface, (CB3T ti parts one example). Check Altera's web site for the > byteblaster MV, there are schematics for the thing up there too, and you > could wire through the RESET line so that all TAP controllers would work. > > Andrew. > > Rob Judd wrote: > > >Hi y'all, > > > >Right, we're making some progress on parts sourcing, thanks in no small > >way to some of you out there who shall remain nameless to avoid > >embarrassment. (Thanks!) > > > >What has come up next is the requirement for a JTAG programmer. I've > >found one here: > > > >http://www.ee.latrobe.edu.au/~djc/PALS/SMALL_PALS.htm > > > >but wonder whether using it on devices only capable of 3v3 or lower may > >kill them. I'm also wondering whether some of the chips I'm considering > >(Actel APA150, Altera EP1C3/EP1C6, Atmel AT94K05, Xilinx > >XC2S200E/XC3S200 and Lattice OR3T80) have particular programming needs > >that make a generic JTAG pod unworkable. If it merely requires level > >translation, I'm golden. > > > >Comments? > > > >Rob > > > >Article: 58988
Peter Ryser wrote: > One reason is the OCP support in > the open source kernel being broken at the moment (or at least the last time > I checked). It sure is! I'm bringing across the PPC kernel drivers into uClinux at the moment, and there's some funny stuff going on in there! Some wierd hard-coded assumptions about the names given to OPB peripherals, and some other crazy things - but the workaround was quite simple. Good news though, I have got the GPIO and ethernet drivers to compile and link essential as-is on microblaze uClinux - things are moving quickly. Peter, I know there are some issues with the ethernet driver re: scatter-gather and DMA - but does it at least work? The reason I ask is that if I spend the time to integrate an ethernet MAC into the microblaze-uclinux hardware target and get the driver in, can I be reasonably confident that the driver itself works properly, and that any errors are therefore mine?! :) Cheers, JohnArticle: 58989
Jon Masters wrote: > Hi, > > I contacted Insight Memec about obtaining a Virtex II 1000 development > board for home use. I trust this is the board you are using? correct. I've got an earlier, revision 1 board, they are up to rev 3 now but the same FPGA configuration still works on the newer board. JohnArticle: 58990
Right you are. That solved the problem quite effectively. Thanks. I usually use the default timing for my behavioral sims and I've never run into this kind of issue before. Thanks for your time, everyone. --Iyad On Tue, 5 Aug 2003, Brian Philofsky wrote: > > > > It looks like you are running your clock at 10 GHz. There is a 100ps > propagation delay in the model but that is also your period you have > defined for your simulation clock. I suggest slowing down your clock to > a more realistic speed and that may improve things for you. > > -- Brian > > > io@duke.edu wrote: > > I assert the read address on the falling edge of the clock. On the first > > rising edge that follows, I expect to see the data stored at that read > > address, but instead i have to wait for the second rising clk edge to see > > it. > > > > The vhdl code is below. The waveforms are at www.duke.edu/~io/wave.jpg > > > > Thank you! > > > > library IEEE; > > use IEEE.STD_LOGIC_1164.ALL; > > use IEEE.STD_LOGIC_ARITH.ALL; > > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > use work.constants.all; > > > > library UNISIM; > > use UNISIM.VCOMPONENTS.all; > > > > entity ramtest is > > > > port ( > > we : in std_logic; > > en : in std_logic; > > rst : in std_logic; > > clk : in std_logic; > > addr : in std_logic_vector(8 downto 0); > > di : in std_logic_vector(7 downto 0); > > do : out std_logic_vector(7 downto 0)); > > > > end ramtest; > > > > architecture xilinx of ramtest is > > > > component RAMB4_S8 > > port ( > > WE : IN STD_LOGIC; > > EN : IN STD_LOGIC; > > RST : IN STD_LOGIC; > > CLK : IN STD_LOGIC; > > ADDR : IN STD_LOGIC_VECTOR(8 DOWNTO 0); > > DI : IN STD_LOGIC_VECTOR(7 DOWNTO 0); > > DO : OUT STD_LOGIC_VECTOR(7 DOWNTO 0)); > > end component; > > > > begin -- xilinx > > > > R0 : RAMB4_S8 port map ( > > WE => we, > > EN => en, > > RST => rst, > > CLK => clk, > > ADDR => addr, > > DI => di, > > DO => do); > > > > > > end xilinx; > > > > > > On Tue, 5 Aug 2003, Jim Wu wrote: > > > > > >>My apologies if it is too obvious, but did you count the clock cycle > >>that sets up the read address as one of the TWO clock cycles? > >> > >>If you can post your code or waveform, that would be helpful. > >> > >>Jim Wu > >>jimwu88NOOOOOSPAM@yahoo.com > >> > >>io@duke.edu wrote in message news:<Pine.GSO.4.56.0308051041170.29999@hudson11.acpub.duke.edu>... > >> > >>>Hi - > >>> > >>>I am trying to run a very simple simulation to verify the functionality of > >>>the "block ram" component in my spartan ii fpga. I am using modelsim > >>>tools that I downloaded from the xilinx website, and I'm using the > >>>"ramb4_s8" primitive. The simulation appears to work properly except that > >>>there appears to be a delay of one clock cycle when reading from the > >>>memory. In other words, if I enable the ram, deassert the write enable, > >>>and select the read address, I need TWO rising clock edges to get the > >>>correct data to appear at the data_out port. I am doing a simple > >>>behavioral simulation so there shouldn't be any delay issues involved. > >>>The data sheet clearly shows that I should only need one rising clock edge > >>>to execute the read. Any ideas? Thanks very much!!! > >>> > >>>--Iyad > >>> > >>>------------------------------- > >>>Iyad Obeid > >>>Dept. of Biomedical Engineering > >>>Duke University > >>>io@duke.edu > >>>(919)660-5104 www.duke.edu/~io > >> > > > > ------------------------------- > > Iyad Obeid > > Dept. of Biomedical Engineering > > Duke University > > io@duke.edu > > (919)660-5104 www.duke.edu/~io > > > ------------------------------- Iyad Obeid Dept. of Biomedical Engineering Duke University io@duke.edu (919)660-5109 www.duke.edu/~ioArticle: 58991
Here is what should work: You decide on a clock edge (polarity), either rising or falling. Right before this clock edge ( set-up time is very short, about 1 ns) you must have valid address and valid clock enable and Read/write control. A few nanoseconds ( 3ns?) after this clock edge you see the data on the Dout lines. If you do a write the same way, you will also always read the data that you addressed. In Virtex-II you have a choice to read the old (previous) data or the new data (the one you are just writing) Set-up and hold times are extremely short: clock-to-out delay is relatively long ( since it includes decoding and other delays). Peter Alfke =================== io@duke.edu wrote: > > I assert the read address on the falling edge of the clock. On the first > rising edge that follows, I expect to see the data stored at that read > address, but instead i have to wait for the second rising clk edge to see > it. > > The vhdl code is below. The waveforms are at www.duke.edu/~io/wave.jpg > > Thank you! > > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > use work.constants.all; > > library UNISIM; > use UNISIM.VCOMPONENTS.all; > > entity ramtest is > > port ( > we : in std_logic; > en : in std_logic; > rst : in std_logic; > clk : in std_logic; > addr : in std_logic_vector(8 downto 0); > di : in std_logic_vector(7 downto 0); > do : out std_logic_vector(7 downto 0)); > > end ramtest; > > architecture xilinx of ramtest is > > component RAMB4_S8 > port ( > WE : IN STD_LOGIC; > EN : IN STD_LOGIC; > RST : IN STD_LOGIC; > CLK : IN STD_LOGIC; > ADDR : IN STD_LOGIC_VECTOR(8 DOWNTO 0); > DI : IN STD_LOGIC_VECTOR(7 DOWNTO 0); > DO : OUT STD_LOGIC_VECTOR(7 DOWNTO 0)); > end component; > > begin -- xilinx > > R0 : RAMB4_S8 port map ( > WE => we, > EN => en, > RST => rst, > CLK => clk, > ADDR => addr, > DI => di, > DO => do); > > end xilinx; > > On Tue, 5 Aug 2003, Jim Wu wrote: > > > My apologies if it is too obvious, but did you count the clock cycle > > that sets up the read address as one of the TWO clock cycles? > > > > If you can post your code or waveform, that would be helpful. > > > > Jim Wu > > jimwu88NOOOOOSPAM@yahoo.com > > > > io@duke.edu wrote in message news:<Pine.GSO.4.56.0308051041170.29999@hudson11.acpub.duke.edu>... > > > Hi - > > > > > > I am trying to run a very simple simulation to verify the functionality of > > > the "block ram" component in my spartan ii fpga. I am using modelsim > > > tools that I downloaded from the xilinx website, and I'm using the > > > "ramb4_s8" primitive. The simulation appears to work properly except that > > > there appears to be a delay of one clock cycle when reading from the > > > memory. In other words, if I enable the ram, deassert the write enable, > > > and select the read address, I need TWO rising clock edges to get the > > > correct data to appear at the data_out port. I am doing a simple > > > behavioral simulation so there shouldn't be any delay issues involved. > > > The data sheet clearly shows that I should only need one rising clock edge > > > to execute the read. Any ideas? Thanks very much!!! > > > > > > --Iyad > > > > > > ------------------------------- > > > Iyad Obeid > > > Dept. of Biomedical Engineering > > > Duke University > > > io@duke.edu > > > (919)660-5104 www.duke.edu/~io > > > > ------------------------------- > Iyad Obeid > Dept. of Biomedical Engineering > Duke University > io@duke.edu > (919)660-5104 www.duke.edu/~ioArticle: 58992
"Rob Judd" <judd@ob-wan.com> wrote in message news:3F2E2B51.DF30933F@ob-wan.com... > Marc, > > By a very strange coincidence, a Belgian friend of mine (well, he's from > Bruges so he's a bit weird :) who designs very tiny RF and micro boards > (mostly portable stuff using MSP430) happened to have a kit from > www.kanda.com that uses the AT40K chip. He offered it to me - complete > with tool chain - for as long as I need it. > > So, it looks like I'm AVR'ing for now, but I'd rather be drinking a nice cold Orval. > > Rob > Fill us in later on. I'd love to here how it turns out. Prefer Duvel myself as heavy beer for every occasion. For most of the other more special beers I tend to forget what each one tastes like, which gives me an excuse to try them all again later :-) Orval is a bit bitter though, of the Trappist beers I prefer something like a Westmalle Triple. Liked your Australian expat story about new-years eve in Belgium. Just give a mail if you're ever back in Belgium and want to go and have a drink. Regards, MarcArticle: 58993
End of Early Registration and Program Announcement
6th MAPLD International Conference
Ronald Reagan Building and International Trade
Center
Washington, D.C.
9-11 September 2003
About 120 papers on programmable devices and technologies
and
related aspects of digital engineering will be presented at
the 6th Military and Aerospace Programmable Logic Devices
(MAPLD) International Conference. Early registration closes
Friday, August 8, 2003.
This year, there will be special emphasis on the following
themes:
Reliability of Hardware and Designs; Fault Tolerance
Reconfigurable/Adaptive Computing Systems
Long-term (> 15 years) Space Missions
Hardware and Software: The Line is Blurring
Radiation Hardening by Design
Digital Signal Processing with Programmable Devices
Design Security
"War Stories" and Lessons Learned
CONFERENCE HOME PAGE - http://klabs.org/mapld03 contains
registration information, paper titles, authors, and
abstracts,
as well as biographies of all invited speakers and Panel
Session
members. Late abstract submissions will be accepted for the
Poster Session.
Invited Speakers Include (more to be announced):
Theron M. Bradley Jr. Greg Hinckley
Chief Engineer, NASA President, Mentor Graphics
"Welcome and Opening Remarks" "Mil/Aero and PLD's: A
CEO's View"
SEMINARS - Two seminars will be presented:
"Advanced Design: Digital Signal Processing, Programmable
Device
Architecture, and Military/Aerospace Applications" and
"Reconfigurable Computing: FPGA-Based, General Purpose, High
Performance Systems."
PANEL SESSION: We will have leading engineers and managers
on our
panel for a spirited "discussion." One question left open
from the
2002 panel on "Why Is Mars So Hard?" that will be discussed
at the
2003 panel is ...
"Why Is Software So Hard?"
A Discussion of the Technical, Programmatic, and
Political Factors That Have Lead To Failures Over
the
Last 40 Years and Its Impact for Future Systems
Introduction:
James Tomayko Carnegie Mellon University
Paul Cerruzi National Air and Space Museum
Opening Case Studies:
Tony Spear, JPL Magellan and Mars Pathfinder
John P. Dimtroff Aircraft Certification Engineer,
FAA
Jack Garman Lockheed-Martin (NASA, retired)
Nancy Leveson Prof. of Aeronautics and
Astronautics, MIT
Jim Lewis SynthWorks Design Inc.
Fred Martin Averstar/Intermetrics
Steven S. Scott Chief Engineer, Goddard Space
Flight Center
Kevin Tones NASA Johnson Space Center
TECHNICAL SESSIONS:
Applications: Military and Aerospace
Systems and Design Tools
Radiation and Mitigation Techniques
Processors: General Purpose and Arithmetic
Reconfigurable Computing, Evolvable Hardware, and
Security
Birds of a Feather: Reconfigurable Computing
Birds of a Feather: Mitigation Methods for
Reprogrammable
Logic in the Space Radiation
Environment
Poster Session
The 6th MAPLD International Conference is hosted by the AIAA
and the
NASA Office of Logic Design.
INDUSTRIAL and GOVERNMENT EXHIBIT RESERVATIONS
AccelChip ACT/CoreTech Actel
Aeroflex UTMC AIAA AITech
Aldec Altera Andraka
Group
Annapolis Micro AstroExpo.com BAE Systems
Celoxica Condor Engineering DSP
Architectures
Elanix Global Velocity Hier Design
IEEE Lattice Semiconductor Mathstar
Mentor Graphics Mission Research Nallatech
Northrop Grumman Quickflex Quicksilver
Tech.
Seakr Space Micro Synthworks
Design
Tensilica Xilinx
NASA Office of Logic Design
For more information, please visit http://klabs.org/mapld03
or contact:
Richard Katz - Conference Chair NASA Goddard Space
Flight Center
mapld2003@klabs.org Tel: (301) 286-9705
Article: 58994news@rtrussell.co.uk wrote: > > Arthur <arthuryang42spam@yahoo.com> wrote: > : Your design should fit going from the 9500 to the 9500xl. The 9500xl > : actually has more function block fanin (36 to 54!) so I would think > : that there should be no fitting issues. > > That's what I hoped, but no luck (so far). > > : The loss of wire-anding would cause your PTerm requirements to > : increase. Perhaps if you were near the maximum utilization for this it > : would not fit. > > I suspect that is it. The report I get from the failed XC9536XL fit is: > > "Mapping a total of 36 equations into 2 function blocks...... > ERROR:Cpld:935 - Cannot place signal P<3>. Consider reducing > the collapsing input limit or the product term limit to prevent > the fitter from creating high input and/or high product term > functions". If the fitter has not at this stage reported the Prod terms, you could re-target a 9572XL,(just for the purposes of getting a complete fitter report!), and then compare with the one below. It's common for fitter reports to be sparse/terse on failure, so you are sometimes best to use a 'does fit' pathway - even if that needs some gyrations ! :) -jg > When successfully put into an XC9536 the report says: > > Macrocells used: 36/36 (100%) > Product terms used: 146/180 (81%) > Registers used: 36/36 (100%) > Pins used: 34/34 (100%) > Function block inputs used: 56/72 (77%) > > There are lots of signals shown as "wire-AND input". > > : You may want to try contacting the Xilinx hotline. They are willing to > : try fitting close designs. > > I'll try that. > > Richard. > http://www.rtrussell.co.uk/Article: 58995
> It sure is! I'm bringing across the PPC kernel drivers into uClinux at > the moment, and there's some funny stuff going on in there! Some wierd > hard-coded assumptions about the names given to OPB peripherals, and > some other crazy things - but the workaround was quite simple. I'd be interested to hear what the workaround is. > The reason I ask is that if I spend the time to integrate an ethernet > MAC into the microblaze-uclinux hardware target and get the driver in, > can I be reasonably confident that the driver itself works properly, and > that any errors are therefore mine?! :) The Ethernet works fine in interrupt driven mode. It doesn't work for SGDMA. - PeterArticle: 58996
Yes, you can do it, but can you do it for "local/remote update mode" (ie MSEL2 = 1). "Valeria Dal Monte" <prova@microsoft.com> wrote in message news:<seHXa.226441$lK4.6759497@twister1.libero.it>... > Wilhelm Klink <kommandantklink@hotmail.com> wrote in message > 6011e208.0308042011.5bdae5e1@posting.google.com... > > Altera have told me it is not possible to perform a multiple device > > configuration (typically done by hooking up the nCE/nCEO pins of the > > individual FPGAs) when using local update mode (update over ethernet). > > Does anyone know why it isn't possible? It is not reasonable for a > > board with 10 FPGAs to have 10 separate ethernet connections, and > > having to update a set of these boards in the field using a > > programming cable would be most tedious. > > Regardless of ethernet, at least for the passive serial configuration mode > in SRAM devices, it is possible. I did it.Article: 58997
Peter Ryser wrote: >>It sure is! I'm bringing across the PPC kernel drivers into uClinux at >>the moment, and there's some funny stuff going on in there! Some wierd >>hard-coded assumptions about the names given to OPB peripherals, and >>some other crazy things - but the workaround was quite simple. > > > I'd be interested to hear what the workaround is. Assuming we are talking about the same thing, the problem is illustrated as follows: (example from drivers/char/xilinx_gpio): [jwilliam@g435-9029 xilinx_gpio]$ grep BASEADDR *.c adapter.c: = XPAR_GPIO_0_HIGHADDR - XPAR_GPIO_0_BASEADDR + 1; xgpio_g.c: XPAR_MY_OPB_GPIO_0_BASEADDR} xgpio_g.c: XPAR_MY_OPB_GPIO_1_BASEADDR} So adapter.c and the xilinx driver code has different expectations on the names of the peripherals (as defined in system.mhs). I just hacked the xxxx_g.c files to use the same names as those expected by adapter.c. Or are you talking about something different? Cheers, JohnArticle: 58998
Hi all:
I have the following verilog codes which shift the serial data to parallel
data.But it cost
too much LEs in Altera FPGA.Then I want to make it wokes in EAB.I do not
what to do.Anybody would help me?
reg[31:0] reg_in[7:0],reg_out[7:0];
always @(posedge clk)
begin
if(reset)
cnt8<=0;
else
if(cnt8==7)
begin
cnt8<=0;
reg_out[0]<=reg_in[0];
reg_out[1]<=reg_in[1];
reg_out[2]<=reg_in[2];
reg_out[3]<=reg_in[3];
reg_out[4]<=reg_in[4];
reg_out[5]<=reg_in[5];
reg_out[6]<=reg_in[6];
reg_out[7]<=reg_in[7];
end
else
begin
cnt8<=cnt8+1;
reg_in[0]<=reg_in[1];
reg_in[1]<=reg_in[2];
reg_in[2]<=reg_in[3];
reg_in[3]<=reg_in[4];
reg_in[4]<=reg_in[5];
reg_in[5]<=reg_in[6];
reg_in[6]<=reg_in[7];
reg_in[7]<=data_receive;
end
end
Article: 58999I've installed sp1 of AHDL, the problem still exists. But I just tried its flow with ISE5.2. "Paul Baxter" <pauljnospambaxter@hotnospammail.com> Π΄ΘλΟϋΟ’ΠΒΞΕ :3f300a06$0$11375$cc9e4d1f@news.dial.pipex.com... > Have you tried AHDL 6.1 service pack 1? > > Though using it with Altera (cos I have to) there are various fixes to bits > and pieces. YMMV > > "Jay" <yuhaiwen@hotmail.com> wrote in message > news:bgnoeu$qa34o$1@ID-195883.news.uni-berlin.de... > > When both of them were installed on my pc, I found: > > 1.ModelSim can't compile Xilinx library > > 2.ISE will give a fatal error when ActiveHDL try generate post-PAR timing > > simulation model > > > > and they both can work well separately. > > > > > >
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