Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 104425

Article: 104425
Subject: Re: Xilinx Floating Point C Simulation aka VHDL/Verilog --> C Conversion?
From: "Simon Heinzle" <sheinzle@inf.ethz.ch>
Date: Tue, 27 Jun 2006 13:06:42 +0200
Links: << >>  << T >>  << A >>
Hi Hans,

also see my other post.

> Can't you co-simulate? that is, put a SystemC/FLI/VHPI wrapper around your 
> C code and load that into your simulator? Alternatively, use shared 
> memory/files/sockets to communicate between your C code and your 
> simulator.

I need floating point operators which produce the same result as the Xilinx 
FP Cores (bit-accurate, not cycle accurate). Shared memory/files/sockets 
sound like a lot of work.

> If you do translate,  how are you planning to validate your translated 
> model? Remember you are converting from a concurrent to a sequential 
> language which might not be that easy...,

I think the Xilinx Cores don't include feedback paths, only a forward 
pipeline. This should not be so difficult to translate. Validation could be 
done by applying the same stimuli to a HDL and the C Simulation and 
comparing the outputs.

Thanks,
Simon 



Article: 104426
Subject: Re: Synplify & Fedora core 5
From: "Simon Heinzle" <sheinzle@inf.ethz.ch>
Date: Tue, 27 Jun 2006 14:03:50 +0200
Links: << >>  << T >>  << A >>
Hi Gilles,

try to set the env variable

  export LD_ASSUME_KERNEL=2.4.1

(when using bash) and then run Synplify. Perhaps that helps?

Best,
Simon

"Gilles GEORGES" <georges@irisa.fr> wrote in message 
news:e7r0lp$23a$1@amma.irisa.fr...
> Dear all,
>
> I'm trying to install a FPGA development platform under a Linux Fedora 
> Core 5.
> The only tool not working is Synplify. I have tried two different versions 
> (7.3.3 and 8.5.1) but got same problem.
>
> when trying to launch synplify_pro i got this :
> ---------------------------------------------
> [georges@remix0 share]$ /local/share/fpga_85/bin/synplify_pro
>
> ***************************************************************
>
> Warning: You are running on an unsupported platform
>   'synplify_pro' only supports Redhat Enterprise Linux 3,4, SuSE 
> Enterprise Linux Server 9
>
>   current platform: Fedora Core release 5 (Bordeaux)
> Kernel \r on an \m
>
> ***************************************************************
>
> /local/share/fpga_85/linux/mbin/synplify: relocation error: 
> /local/share/fpga_85/linux/mfw/lib-linux_optimized/libkernel32.so: symbol 
> errno, version GLIBC_2.0 not defined in file libc.so.6 with link time 
> reference
> [georges@remix0 share]$
> -------------------------------------------
>
> The FC5 seems not to be supported, does anyone experience to make it run 
> under FC5 ?
> I plan to try why a FC4, any expérience ?
>
> Thanks in advance
>
> Gilles 



Article: 104427
Subject: Help in the platform studio(EDK)
From: "subint" <subin.82@gmail.com>
Date: 27 Jun 2006 05:48:50 -0700
Links: << >>  << T >>  << A >>
Hi,
I am using the platform studio first time.I like to know how i can add
my testbenches and remove the microblaze processor from the setup.
       I am trying to generate the controller for my V4MB lx60 board
and i want to test the ddr in the board.From the tool(platform studio)
i can select the pheripherals and the processor etc but didnt have any
idea how can i use this to test my ddr.I tried to generate the hdl
code.But all the controllers are ipcores(black box) and i wont be able
to synthesize it using xilinx ise(library for these ipcores are
missing).
regards
subin


Article: 104428
Subject: XilFatFS and CF...
From: "The Mighty Shaman" <mighty@shaman.com>
Date: Tue, 27 Jun 2006 06:11:09 -0700
Links: << >>  << T >>  << A >>
Hi there, I'm experiencing some problems with a 64 MB Compact Flash and xilfatfs on the XUP board: since I wasn't able to open in write mode more than one file each time, I tried to reformat the Compact Flash. I reformatted it with mkdosfs in FAT16 and it works perfectly for reprogramming the FPGA, but now I can't open any file in write mode (although everything seems correct in the software platform settings: write support is enabled). Does anybody has any idea why it doesn't work? Any possible solution?

Thank you very much!!!

The Mighty Shaman

Article: 104429
Subject: Once synthesized RAMs are vanishing in WebPACK 8.1i03
From: user@domain.invalid
Date: Tue, 27 Jun 2006 15:38:37 +0200
Links: << >>  << T >>  << A >>
    Hello all,

Using WebPACK version 8.1i03 initially synthesized RAM vanishes later in
the design???
The design works perfectly OK in WebPACK version 7.1i04, so I would assume that something
drastic as this should not happen.
The VHDL code also works on Altera FPGAs.
I am using Spartan3 here.

I must be doing something obviously wrong, but what?
Anyone can shed a light on it? It would be much appreciated.

,
The design is the 8051-microcontroller, version 1.4, with patches from
             http://www.oregano.at/ip/8051.htm

Initially all RAM's are synthesized as in the 7.1i version, but are later largely removed.
The VHDL code of one of the RAMs can be found below.
The directory with the complete design can be found at
              http://www.cs.rug.nl/~sietse/8051

But here are the relevant (i think) parts of the log:

FROM THE SYNTHESIS REPORT:
=========================

Synthesizing Unit <mc8051_ramx>.
     Related source file is "/net/users/sietse/FPGA/versie-8.1i/8051/geheugen.vhdl".
WARNING:Xst:647 - Input <reset> is never used.
WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
     Found 8192x8-bit single-port block RAM for signal <extram>.
     -----------------------------------------------------------------------
     | mode               | read-first                          |          |
     | aspect ratio       | 8192-word x 8-bit                   |          |
     | clock              | connected to signal <clk>           | rise     |
     | write enable       | connected to signal <ram_wr_i>      | high     |
     | address            | connected to signal <int_ram_adr>   |          |
     | data in            | connected to signal <ram_data_i>    |          |
     | data out           | connected to signal <ram_data_o>    |          |
     | ram_style          | Auto                                |          |
     -----------------------------------------------------------------------
     Summary:
	inferred   1 RAM(s).
Unit <mc8051_ramx> synthesized.

AND SIMILAR FOR THE OTHER RAMs. AND THEN LATER:
==============================================

Macro Statistics
# Block RAMs                                           : 3
  128x8-bit single-port block RAM                       : 1
  16384x8-bit single-port block RAM                     : 1
  8192x8-bit single-port block RAM                      : 1

SO THE RAMs are synthesized initially!
======================================
THEN A NUMBER (7) OF STRANGE INFOs:
===================================

INFO:Xst:2399 - RAMs <inst_Mram_mem51>, <inst_Mram_mem41> are equivalent, second RAM is removed

DON'T KNOW WHAT THIS MEANS.
AND THE FINAL (synthesizer) REPORT NOTES:
===========================
# RAMS                             : 2
#      RAMB16_S1                   : 1
#      RAMB16_S9                   : 1

SO MOST RAMs ARE GONE!!!
=======================
=======================

What is going wrong here? Anyone an idea?

I also installed the WebPack on two different machines.

    Regards,
      Sietse Achterop
      Computing Science department
      University of Groningen

PS. I want to use this design in a number of courses that I am giving here.


===============================================================
The VHDL RAM descriptions are like:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;

entity mc8051_ramx is

   port (clk        : in  std_logic;  			 -- clock signal
         reset      : in  std_logic;  			 -- reset signal
         ram_data_i : in  std_logic_vector(7 downto 0);   -- data input
         ram_data_o : out std_logic_vector(7 downto 0);   -- data output
         ram_adr_i  : in  std_logic_vector(15 downto 0);  -- adresses
         ram_wr_i   : in  std_logic);  			 -- read=0, write=1

end mc8051_ramx;


architecture behav of mc8051_ramx is

   type   ram_type is array (8191 downto 0) of std_logic_vector(7 downto 0);

   signal extram: ram_type;
   signal int_ram_adr : std_logic_vector(12 downto 0);

begin
   int_ram_adr <= ram_adr_i(12 downto 0);

   p_read : process (clk)
   begin
     if rising_edge(clk) then
         ram_data_o <= extram(conv_integer(unsigned(int_ram_adr)));
     end if;
   end process p_read;

   p_write : process (clk)
   begin
     if rising_edge(clk) then
         if (ram_wr_i='1') then
           extram(conv_integer(unsigned(int_ram_adr))) <= ram_data_i;
         end if;
     end if;
   end process p_write;

end behav;

Article: 104430
Subject: Re: need help plz.
From: lb.edc@telenet.be
Date: Tue, 27 Jun 2006 13:39:22 GMT
Links: << >>  << T >>  << A >>
Implement a UART on your 10KE. I assume that when you're able to build
CDMA, then a UART will be a piece of cake.

Regards,

Luc

On 27 Jun 2006 03:27:41 -0700, "lenile84" <EzzEldine@gmail.com> wrote:

> i need  a VHDL code for interface between a pc and FPGA kit (flex10ke)
>to exchange data.
>this programme i will use to make a demo for our project which is
>implementing CDMA is95 on the that kit by sending users from serial
>port on pc to kit and receive it again to another pc .
>the two pc act as BAse station and mobile set. thanks in advance.
>e-mail ezzeldine@gmail.com

Article: 104431
Subject: Re: Once synthesized RAMs are vanishing in WebPACK 8.1i03
From: user@domain.invalid
Date: Tue, 27 Jun 2006 15:45:05 +0200
Links: << >>  << T >>  << A >>
user@domain.invalid wrote:
 > something

   I don't know whats wrong here, but my email is:
     sietse@cs.rug.nl

    Regards,
      Sietse Achterop

Article: 104432
Subject: Re: Synplify & Fedora core 5
From: Gilles GEORGES <georges@irisa.fr>
Date: Tue, 27 Jun 2006 15:46:30 +0200
Links: << >>  << T >>  << A >>
Hi Simon,

I already tried this but the use of LD_ASSUME_KERNEL is not supported 
with Fedora Core 5.
Nothing working when setting this variable, so not the issue for this 
problem.

Thanks
Gilles

Simon Heinzle a écrit :
> Hi Gilles,
> 
> try to set the env variable
> 
>   export LD_ASSUME_KERNEL=2.4.1
> 
> (when using bash) and then run Synplify. Perhaps that helps?
> 
> Best,
> Simon
> 
> "Gilles GEORGES" <georges@irisa.fr> wrote in message 
> news:e7r0lp$23a$1@amma.irisa.fr...
> 
>>Dear all,
>>
>>I'm trying to install a FPGA development platform under a Linux Fedora 
>>Core 5.
>>The only tool not working is Synplify. I have tried two different versions 
>>(7.3.3 and 8.5.1) but got same problem.
>>
>>when trying to launch synplify_pro i got this :
>>---------------------------------------------
>>[georges@remix0 share]$ /local/share/fpga_85/bin/synplify_pro
>>
>>***************************************************************
>>
>>Warning: You are running on an unsupported platform
>>  'synplify_pro' only supports Redhat Enterprise Linux 3,4, SuSE 
>>Enterprise Linux Server 9
>>
>>  current platform: Fedora Core release 5 (Bordeaux)
>>Kernel \r on an \m
>>
>>***************************************************************
>>
>>/local/share/fpga_85/linux/mbin/synplify: relocation error: 
>>/local/share/fpga_85/linux/mfw/lib-linux_optimized/libkernel32.so: symbol 
>>errno, version GLIBC_2.0 not defined in file libc.so.6 with link time 
>>reference
>>[georges@remix0 share]$
>>-------------------------------------------
>>
>>The FC5 seems not to be supported, does anyone experience to make it run 
>>under FC5 ?
>>I plan to try why a FC4, any expérience ?
>>
>>Thanks in advance
>>
>>Gilles 
> 
> 
> 

Article: 104433
Subject: Re: VHDL model for Micron SDRAM simulation ?
From: "Nial Stewart" <nial@nialstewartdevelopments.co.uk>
Date: Tue, 27 Jun 2006 14:53:57 +0100
Links: << >>  << T >>  << A >>
"sjulhes" <t@aol.fr> wrote in message news:449fff97$0$31655$636a55ce@news.free.fr...
> Thanks for the answers but as I don't know anything in verilog (!) could someone give me a little 
> example of how to declare a verilog component in a vhdl file and how to instanciate it in the vhdl 
> file.
> Thank you.
> Stéphane.


As Duane shows below(/above), a single wire maps to std_logic and a vector to a
std_logic_vector of the correct width.


Nial. 



Article: 104434
Subject: Re: VHDL model for Micron SDRAM simulation ?
From: "sjulhes" <t@aol.fr>
Date: Tue, 27 Jun 2006 16:10:42 +0200
Links: << >>  << T >>  << A >>
Thank you for your help, I did manage to make my VHDL bench compile with the 
verilog model.

Stéphane.

"Duane Clark" <junkmail@junkmail.com> a écrit dans le message de news: 
SYTng.73160$4L1.13281@newssvr11.news.prodigy.com...
> sjulhes wrote:
>> Thanks for the answers but as I don't know anything in verilog (!) could 
>> someone give me a little example of how to declare a verilog component in 
>> a vhdl file and how to instanciate it in the vhdl file.
>
> There is no special syntax for Verilog models. For instance, I use the 
> Micron models for the mt16vddf12864. It starts out with:
>
> module mt16vddf12864 (Dq, Dqs, Addr, Ba, Clk, Clk_n, Cke, Cs_n, Ras_n, 
> Cas_n, We_n, Dm);
>   inout [0 : 63] Dq;
>   inout  [0 : 7] Dqs;
>   input [0 : 12] Addr;
>   input  [0 : 1] Ba;
>   input  [0 : 2] Clk;
>   input  [0 : 2] Clk_n;
>   input  [0 : 1] Cke;
>   input  [0 : 1] Cs_n;
>   input          Ras_n;
>   input          Cas_n;
>   input          We_n;
>   input  [0 : 7] Dm;
>
>
> And it is compiled into the work directory with:
> vlog mt16vddf12864.v
>
>
> My testbench contains:
>
>    -- MICRON DDR SDRAM Simulation Model
>    DIMM : entity mem.MT16VDDF12864
>    port map (
>       Dq             => DDR_DQ,
>       Dqs            => DDR_DQS,
> --      Addr           => DDR_Addr(C_DDR_AWIDTH-11 to 12),
>       Addr           => DDR_Addr(0 to 12),
>       Ba             => DDR_BankAddr,
>       Clk(0)         => DDR_Clk_0,
>       Clk(1)         => DDR_Clk_1,
>       Clk(2)         => DDR_Clk_0,
>       Clk_n(0)       => DDR_Clkn_0,
>       Clk_n(1)       => DDR_Clkn_1,
>       Clk_n(2)       => DDR_Clkn_0,
>       Cke            => DDR_CKE,
>       Cs_n           => DDR_CSn,
>       Ras_n          => DDR_RASn,
>       Cas_n          => DDR_CASn,
>       We_n           => DDR_WEn,
>       Dm             => DDR_DM
>    );
>
> Where my project.mpf file contains:
> [Library]
> mem = $MODELS/mem/work
>
> Which is where I compiled the Micron models. 



Article: 104435
Subject: dcm clkin_divide_by_2
From: Matt Blanton <notreally@myemail.com>
Date: Tue, 27 Jun 2006 10:11:19 -0400
Links: << >>  << T >>  << A >>
When using the dcm clkin_divide_by_2 attribute on a V2P DCM, if the clk0
output is fed into the clkfb input, will clk0 be in phase with clkin?

Matt

Article: 104436
Subject: Montavista linux Xilinx Virtex4 ML403
From: tester <test@test.de>
Date: Tue, 27 Jun 2006 16:19:03 +0200
Links: << >>  << T >>  << A >>
I have a monta vista linux preview kit 3.1 runnig on a ml403 GSRD based 
  design. Now i have the problem to get the linux runnig out of the 
compact flash card from Systemace on ML403. Who has as solution for that

Article: 104437
Subject: Re: Xilinx Floating Point C Simulation aka VHDL/Verilog --> C Conversion?
From: christopher.saunter@durham.ac.uk (c d saunter)
Date: Tue, 27 Jun 2006 14:22:00 +0000 (UTC)
Links: << >>  << T >>  << A >>
Simon Heinzle (sheinzle@inf.ethz.ch) wrote:
: Hi John and cds,

: We have an arithmetic C model with standard IEEE single precision floats. 
: However, in our FPGA implementation we use several different (custom) 
: floating point formats, mainly due to the limited resources.

: The C model is used to generate stimuli vectors for the HDL simulation. 
: Surely we play tricks to quantize the intermediate results of the single 
: precision operations, but the results often differ (in a few bits) from the 
: HDL simulation, which is quite annoying (and not practical for automated 
: testing).

: In short: I'm just looking for a bit-accurate (non cycle-accurate) model of 
: the Floating Point Operators from Xilinx.

I'll second that request in light of Ben Jones' posting.

Simon, I don't know if you are aware of GHDL?  It's a VHDL front end for 
GCC which spits out object files, so you may be able to compile the Xilinx 
Behavioural model into a form you can link C code against...

What sort of performance would you be happy with compared to machine 
native floats?

Cheers,
	Chris




Article: 104438
Subject: Re: Once synthesized RAMs are vanishing in WebPACK 8.1i03
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Tue, 27 Jun 2006 15:24:43 +0100
Links: << >>  << T >>  << A >>
you have a 8K memory but it seems from the log file that you are not 
using the all the address bits,
WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
which means that you basically need only 1K from the total of 8K and XST 
remove the rest, I think this make sense if you keep these addresses 
tied to a constant.
Aurash
user@domain.invalid wrote:

>    Hello all,
>
> Using WebPACK version 8.1i03 initially synthesized RAM vanishes later in
> the design???
> The design works perfectly OK in WebPACK version 7.1i04, so I would 
> assume that something
> drastic as this should not happen.
> The VHDL code also works on Altera FPGAs.
> I am using Spartan3 here.
>
> I must be doing something obviously wrong, but what?
> Anyone can shed a light on it? It would be much appreciated.
>
> ,
> The design is the 8051-microcontroller, version 1.4, with patches from
>             http://www.oregano.at/ip/8051.htm
>
> Initially all RAM's are synthesized as in the 7.1i version, but are 
> later largely removed.
> The VHDL code of one of the RAMs can be found below.
> The directory with the complete design can be found at
>              http://www.cs.rug.nl/~sietse/8051
>
> But here are the relevant (i think) parts of the log:
>
> FROM THE SYNTHESIS REPORT:
> =========================
>
> Synthesizing Unit <mc8051_ramx>.
>     Related source file is 
> "/net/users/sietse/FPGA/versie-8.1i/8051/geheugen.vhdl".
> WARNING:Xst:647 - Input <reset> is never used.
> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
>     Found 8192x8-bit single-port block RAM for signal <extram>.
>     
> -----------------------------------------------------------------------
>     | mode               | read-first                          
> |          |
>     | aspect ratio       | 8192-word x 8-bit                   
> |          |
>     | clock              | connected to signal <clk>           | 
> rise     |
>     | write enable       | connected to signal <ram_wr_i>      | 
> high     |
>     | address            | connected to signal <int_ram_adr>   
> |          |
>     | data in            | connected to signal <ram_data_i>    
> |          |
>     | data out           | connected to signal <ram_data_o>    
> |          |
>     | ram_style          | Auto                                
> |          |
>     
> -----------------------------------------------------------------------
>     Summary:
>     inferred   1 RAM(s).
> Unit <mc8051_ramx> synthesized.
>
> AND SIMILAR FOR THE OTHER RAMs. AND THEN LATER:
> ==============================================
>
> Macro Statistics
> # Block RAMs                                           : 3
>  128x8-bit single-port block RAM                       : 1
>  16384x8-bit single-port block RAM                     : 1
>  8192x8-bit single-port block RAM                      : 1
>
> SO THE RAMs are synthesized initially!
> ======================================
> THEN A NUMBER (7) OF STRANGE INFOs:
> ===================================
>
> INFO:Xst:2399 - RAMs <inst_Mram_mem51>, <inst_Mram_mem41> are 
> equivalent, second RAM is removed
>
> DON'T KNOW WHAT THIS MEANS.
> AND THE FINAL (synthesizer) REPORT NOTES:
> ===========================
> # RAMS                             : 2
> #      RAMB16_S1                   : 1
> #      RAMB16_S9                   : 1
>
> SO MOST RAMs ARE GONE!!!
> =======================
> =======================
>
> What is going wrong here? Anyone an idea?
>
> I also installed the WebPack on two different machines.
>
>    Regards,
>      Sietse Achterop
>      Computing Science department
>      University of Groningen
>
> PS. I want to use this design in a number of courses that I am giving 
> here.
>
>
> ===============================================================
> The VHDL RAM descriptions are like:
>
> library IEEE;
> use IEEE.std_logic_1164.all;
> use IEEE.std_logic_arith.all;
>
> entity mc8051_ramx is
>
>   port (clk        : in  std_logic;               -- clock signal
>         reset      : in  std_logic;               -- reset signal
>         ram_data_i : in  std_logic_vector(7 downto 0);   -- data input
>         ram_data_o : out std_logic_vector(7 downto 0);   -- data output
>         ram_adr_i  : in  std_logic_vector(15 downto 0);  -- adresses
>         ram_wr_i   : in  std_logic);               -- read=0, write=1
>
> end mc8051_ramx;
>
>
> architecture behav of mc8051_ramx is
>
>   type   ram_type is array (8191 downto 0) of std_logic_vector(7 
> downto 0);
>
>   signal extram: ram_type;
>   signal int_ram_adr : std_logic_vector(12 downto 0);
>
> begin
>   int_ram_adr <= ram_adr_i(12 downto 0);
>
>   p_read : process (clk)
>   begin
>     if rising_edge(clk) then
>         ram_data_o <= extram(conv_integer(unsigned(int_ram_adr)));
>     end if;
>   end process p_read;
>
>   p_write : process (clk)
>   begin
>     if rising_edge(clk) then
>         if (ram_wr_i='1') then
>           extram(conv_integer(unsigned(int_ram_adr))) <= ram_data_i;
>         end if;
>     end if;
>   end process p_write;
>
> end behav;



-- 
 __
/ /\/\ Aurelian Lazarut
\ \  / System Verification Engineer
/ /  \ Xilinx Ireland
\_\/\/
 
phone:	353 01 4032639
fax:	353 01 4640324
    
     

Article: 104439
Subject: Re: Once synthesized RAMs are vanishing in WebPACK 8.1i03
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Tue, 27 Jun 2006 15:42:07 +0100
Links: << >>  << T >>  << A >>
to be more precise you have:
int_ram_adr <= ram_adr_i(12 downto 0);
 
what about ram_adr_i(15 downto 13) who's driving them ?

Aurash

Aurelian Lazarut wrote:

> you have a 8K memory but it seems from the log file that you are not 
> using the all the address bits,
> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
> which means that you basically need only 1K from the total of 8K and 
> XST remove the rest, I think this make sense if you keep these 
> addresses tied to a constant.
> Aurash
> user@domain.invalid wrote:
>
>>    Hello all,
>>
>> Using WebPACK version 8.1i03 initially synthesized RAM vanishes later in
>> the design???
>> The design works perfectly OK in WebPACK version 7.1i04, so I would 
>> assume that something
>> drastic as this should not happen.
>> The VHDL code also works on Altera FPGAs.
>> I am using Spartan3 here.
>>
>> I must be doing something obviously wrong, but what?
>> Anyone can shed a light on it? It would be much appreciated.
>>
>> ,
>> The design is the 8051-microcontroller, version 1.4, with patches from
>>             http://www.oregano.at/ip/8051.htm
>>
>> Initially all RAM's are synthesized as in the 7.1i version, but are 
>> later largely removed.
>> The VHDL code of one of the RAMs can be found below.
>> The directory with the complete design can be found at
>>              http://www.cs.rug.nl/~sietse/8051
>>
>> But here are the relevant (i think) parts of the log:
>>
>> FROM THE SYNTHESIS REPORT:
>> =========================
>>
>> Synthesizing Unit <mc8051_ramx>.
>>     Related source file is 
>> "/net/users/sietse/FPGA/versie-8.1i/8051/geheugen.vhdl".
>> WARNING:Xst:647 - Input <reset> is never used.
>> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
>>     Found 8192x8-bit single-port block RAM for signal <extram>.
>>     
>> -----------------------------------------------------------------------
>>     | mode               | read-first                          
>> |          |
>>     | aspect ratio       | 8192-word x 8-bit                   
>> |          |
>>     | clock              | connected to signal <clk>           | 
>> rise     |
>>     | write enable       | connected to signal <ram_wr_i>      | 
>> high     |
>>     | address            | connected to signal <int_ram_adr>   
>> |          |
>>     | data in            | connected to signal <ram_data_i>    
>> |          |
>>     | data out           | connected to signal <ram_data_o>    
>> |          |
>>     | ram_style          | Auto                                
>> |          |
>>     
>> -----------------------------------------------------------------------
>>     Summary:
>>     inferred   1 RAM(s).
>> Unit <mc8051_ramx> synthesized.
>>
>> AND SIMILAR FOR THE OTHER RAMs. AND THEN LATER:
>> ==============================================
>>
>> Macro Statistics
>> # Block RAMs                                           : 3
>>  128x8-bit single-port block RAM                       : 1
>>  16384x8-bit single-port block RAM                     : 1
>>  8192x8-bit single-port block RAM                      : 1
>>
>> SO THE RAMs are synthesized initially!
>> ======================================
>> THEN A NUMBER (7) OF STRANGE INFOs:
>> ===================================
>>
>> INFO:Xst:2399 - RAMs <inst_Mram_mem51>, <inst_Mram_mem41> are 
>> equivalent, second RAM is removed
>>
>> DON'T KNOW WHAT THIS MEANS.
>> AND THE FINAL (synthesizer) REPORT NOTES:
>> ===========================
>> # RAMS                             : 2
>> #      RAMB16_S1                   : 1
>> #      RAMB16_S9                   : 1
>>
>> SO MOST RAMs ARE GONE!!!
>> =======================
>> =======================
>>
>> What is going wrong here? Anyone an idea?
>>
>> I also installed the WebPack on two different machines.
>>
>>    Regards,
>>      Sietse Achterop
>>      Computing Science department
>>      University of Groningen
>>
>> PS. I want to use this design in a number of courses that I am giving 
>> here.
>>
>>
>> ===============================================================
>> The VHDL RAM descriptions are like:
>>
>> library IEEE;
>> use IEEE.std_logic_1164.all;
>> use IEEE.std_logic_arith.all;
>>
>> entity mc8051_ramx is
>>
>>   port (clk        : in  std_logic;               -- clock signal
>>         reset      : in  std_logic;               -- reset signal
>>         ram_data_i : in  std_logic_vector(7 downto 0);   -- data input
>>         ram_data_o : out std_logic_vector(7 downto 0);   -- data output
>>         ram_adr_i  : in  std_logic_vector(15 downto 0);  -- adresses
>>         ram_wr_i   : in  std_logic);               -- read=0, write=1
>>
>> end mc8051_ramx;
>>
>>
>> architecture behav of mc8051_ramx is
>>
>>   type   ram_type is array (8191 downto 0) of std_logic_vector(7 
>> downto 0);
>>
>>   signal extram: ram_type;
>>   signal int_ram_adr : std_logic_vector(12 downto 0);
>>
>> begin
>>   int_ram_adr <= ram_adr_i(12 downto 0);
>>
>>   p_read : process (clk)
>>   begin
>>     if rising_edge(clk) then
>>         ram_data_o <= extram(conv_integer(unsigned(int_ram_adr)));
>>     end if;
>>   end process p_read;
>>
>>   p_write : process (clk)
>>   begin
>>     if rising_edge(clk) then
>>         if (ram_wr_i='1') then
>>           extram(conv_integer(unsigned(int_ram_adr))) <= ram_data_i;
>>         end if;
>>     end if;
>>   end process p_write;
>>
>> end behav;
>
>
>
>


-- 
 __
/ /\/\ Aurelian Lazarut
\ \  / System Verification Engineer
/ /  \ Xilinx Ireland
\_\/\/
 
phone:	353 01 4032639
fax:	353 01 4640324
    
     

Article: 104440
Subject: Re: dcm clkin_divide_by_2
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 27 Jun 2006 07:42:16 -0700
Links: << >>  << T >>  << A >>
Matt,

Every other cycle of the input clock (it gets divided by two).

Austin

Matt Blanton wrote:
> When using the dcm clkin_divide_by_2 attribute on a V2P DCM, if the clk0
> output is fed into the clkfb input, will clk0 be in phase with clkin?
> 
> Matt

Article: 104441
Subject: Re: Synplify & Fedora core 5
From: Duane Clark <junkmail@junkmail.com>
Date: Tue, 27 Jun 2006 15:58:06 GMT
Links: << >>  << T >>  << A >>
Gilles GEORGES wrote:
> Dear all,
> 
> I'm trying to install a FPGA development platform under a Linux Fedora 
> Core 5.
> The only tool not working is Synplify. I have tried two different 
> versions (7.3.3 and 8.5.1) but got same problem.
> 

Did you try installing the compatibility libraries? The is, 
compat-libgcc-296 and compat-libstdc++-296.

Article: 104442
Subject: Re: Synplify & Fedora core 5
From: Gilles GEORGES <georges@irisa.fr>
Date: Tue, 27 Jun 2006 18:44:54 +0200
Links: << >>  << T >>  << A >>
Duane Clark a écrit :
> Gilles GEORGES wrote:
> 
>> Dear all,
>>
>> I'm trying to install a FPGA development platform under a Linux Fedora 
>> Core 5.
>> The only tool not working is Synplify. I have tried two different 
>> versions (7.3.3 and 8.5.1) but got same problem.
>>
> 
> Did you try installing the compatibility libraries? The is, 
> compat-libgcc-296 and compat-libstdc++-296.

No i didn't.
I successfully made synplify running under FC4 a few minutes ago.
But thanks for the compatibility library. I will try this way later.

Gilles

Article: 104443
Subject: Re: Xilinx Floating Point C Simulation aka VHDL/Verilog --> C Conversion?
From: "Simon Heinzle" <sheinzle@inf.ethz.ch>
Date: Tue, 27 Jun 2006 18:56:12 +0200
Links: << >>  << T >>  << A >>
Hi Chris,

> I'll second that request in light of Ben Jones' posting.

Dito, I really hope Xilinx will develop the C models.

> Simon, I don't know if you are aware of GHDL?  It's a VHDL front end for
> GCC which spits out object files, so you may be able to compile the Xilinx
> Behavioural model into a form you can link C code against...

Thanks! I'll definitely have a look at that one.

> What sort of performance would you be happy with compared to machine
> native floats?

Hmm, doesn't need to be very fast, but it should be faster than the HDL 
simulation. Compared to native floats, I think there will be a huge 
performance drop (~10 to 100 times slower) when doing it bit-accurate.

Best,
Simon 



Article: 104444
Subject: Re: XilFatFS and CF...
From: Eli Hughes <emh203@psu.edu>
Date: Tue, 27 Jun 2006 13:23:33 -0400
Links: << >>  << T >>  << A >>
The Mighty Shaman wrote:
> Hi there, I'm experiencing some problems with a 64 MB Compact Flash and xilfatfs on the XUP board: since I wasn't able to open in write mode more than one file each time, I tried to reformat the Compact Flash. I reformatted it with mkdosfs in FAT16 and it works perfectly for reprogramming the FPGA, but now I can't open any file in write mode (although everything seems correct in the software platform settings: write support is enabled). Does anybody has any idea why it doesn't work? Any possible solution?
> 
> Thank you very much!!!
> 
> The Mighty Shaman


I suffered greatly with this same problem.  It all comes down to the 
format parameters.   The best way is to get a copy windows 2000 and tell 
it to format in FAT16 at a command prompt with format.com

-Eli

Article: 104445
Subject: Re: keys to the Kingdom
From: mk <kal*@dspia.*comdelete>
Date: Tue, 27 Jun 2006 17:54:24 GMT
Links: << >>  << T >>  << A >>
On 26 Jun 2006 20:18:42 -0700, "Peter Alfke" <alfke@sbcglobal.net>
wrote:

>Isn't Marketing wonderful...
>Here we are discussing which physical implementation is more secure,
>and dear Dave tells us that Altera was indeed smart enough to implement
>the algorithm correctly. I would never have stooped so low to doubt
>that. Yes, Altera can do logic design. Bravo! Advance to second grade!
>
>The question, however, was totally different:  whether the key is
>secure. And that is nowhere mentioned in that long URL.
>Marketing 101:
>If you have nothing good to say, throw in a big bunch of irrelevant
>data.
>That might defuse the argument. and calm down the waves...
>
>Peter Alfke, who had expected a more relevant post from Altera.
>Don't treat us like dummies.

Hi Peter,

Isn't FUD wonderful...

At least they are not claiming anything which they haven't really
accomplished unlike the statements here:

"If I can get the IP that is a secret for less than $5,000, then I can
clone the devices without paying anything at all." 

"*Disclaimer:  non-volatile poly-efuse EM technology can be read out
by a microscope using polarized light for a total investment of less
than $5,000 "

and then changing the numbers when confronted if actually done:

"No, I have not cracked the Altera chip."

"My quote of $5,000 is what we pay to have a device ground down on the
backside such that we can do analysis on a device.

For another $5,000, one can get up to three or four FIB cuts, and a
couple of jumper wires. "

Now we are up to $10K. Then claiming:
"The question is not one of can I crack it (I believe I can), but one
of a ASSP vendor deciding to place their IP in a component that is not
in compliance with FIPS 140-2.  Very, very simple."

I think it's put up or shut-up time, don't you think ? If you guys are
so sure, why don't you crack it / get it cracked and tell us how much
it costs instead of spreading FUD ?

Article: 104446
Subject: Re: Xilinx ML461 memory board, whats the real story?
From: "Peter Alfke" <peter@xilinx.com>
Date: 27 Jun 2006 10:56:22 -0700
Links: << >>  << T >>  << A >>
Hi "lecroy"
I checked with the designer of that board.
It seems that we did not explain the purpose of that cheap little LCD
display. It is not there for debugging the meory interfaces. It is
mainly for displaying some cute lines at shows and conferences.
That's why we do no longer support any interfaces to it.

Use CipScope for serious memory interface debugging.
Here is what I learned from the designer:

" Hi Peter,
The LCD panel is merely a display demo and never calls out errors in
the memory interfaces. In later releases we removed this code to avoid
confusion.

It would help to know exactly what this customer wants. If they just
want an error reporting mechanism then they should use the latest
chipscope demo files.

However, if they want LCD display with error reporting functionality
then we do not have any code for that and they will have to develop it
themselves.

The link to the latest chipscope demo files is below. Please ask your
FAE to download it and send it to you since you might not have access
to this page. The latest rtl code for memory interfaces must be
downloaded from the MIG (Memory Interface Generator) tool.

http://www.partner.xilinx.com/common/hiend/boards/docs/ml461/ML461_Toolkit_050401.zip

End of quote.
I hope this eliminates your frustration, or at least redirects it in
the proper direction
Peter Alfke, Xilinx Applications



lecroy7200@chek.com wrote:
> We purchased an ML461 board in Aug of 05 for $6000 from Avnet.  If I
> follow the documention that came with the board, it has a memory test
> screen that led me to believe that the board is running some sort of
> memory test and reporting errors on the LCD.   If I look at the source
> files the came with the board, they do not appear to be what was used
> to create the actual images being loaded into the board.  So, for
> example, FPGA 4 controls all of the LCD functions, however looking at
> the actual code that was supplied for FPGA 4, there is no support for
> the LCD.  The actual code for FPGA 4, for example will not even compile
> without errors.   What is more strange is that if I look in FPGA 3
> which contains the QDR controller, there appears to be only one signal
> that reports the errors back to FPGA 4 and it is not routed to it.  So,
> there appears to be no way for FPGA to actually detect an error.  For
> fun, if I load FPGA 3 with the binary for FPGA 2, FPGA 4 reports no
> memory errors on the LCD.  Not that this proves that the design was
> faulted, but it does raise my suspicions.  I also found some other pins
> defined in the source files that do not match the schematics that were
> supplied.
>
> I had opened a case, spoke with two different FAEs and even tried to
> get our money back from Avnet.  Avnet claims Xilinx will support the
> board and the last message from them provided me an inside contact at
> Xilinx who was supposed to know this board and be able to help.  When I
> called him a few weeks ago he explained he was in marketing, not
> engineering and suggested that I open a case number with Xilinx, which
> I have, yet again.   I have now came full circle with this board.
>
> Does anyone here have all of the code that was used to create the
> images for this board?


Article: 104447
Subject: Re: Once synthesized RAMs are vanishing in WebPACK 8.1i03
From: Sietse Achterop <sietse@cs.rug.nl>
Date: Tue, 27 Jun 2006 20:17:29 +0200
Links: << >>  << T >>  << A >>
Aurelian Lazarut wrote:
> to be more precise you have:
> int_ram_adr <= ram_adr_i(12 downto 0);
> 
> what about ram_adr_i(15 downto 13) who's driving them ?
> 
> Aurash
> 
> Aurelian Lazarut wrote:
> 
>> you have a 8K memory but it seems from the log file that you are not 
>> using the all the address bits,
>> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
>> which means that you basically need only 1K from the total of 8K and 
>> XST remove the rest, I think this make sense if you keep these 
>> addresses tied to a constant.
>> Aurash

    Hello Aurash,

thanks for the prompt reply.
     (the 8KB memory serves as the external RAM of the 8051)
But 8 KByte uses 13 address bits, so that's ok. The 8051 cpu has 16 
address bits and only 13 bits for the lower 8 KB are used.
Or better, the 8KB is repeated 8 times in the 64KB address space.
So all 13 address lines for the RAM are used, and I don't see why
it is optimized away.

   Sietse

Article: 104448
Subject: Re: Once synthesized RAMs are vanishing in WebPACK 8.1i03
From: mk <kal*@dspia.*comdelete>
Date: Tue, 27 Jun 2006 18:33:55 GMT
Links: << >>  << T >>  << A >>
On Tue, 27 Jun 2006 20:17:29 +0200, Sietse Achterop <sietse@cs.rug.nl>
wrote:

>Aurelian Lazarut wrote:
>> to be more precise you have:
>> int_ram_adr <= ram_adr_i(12 downto 0);
>> 
>> what about ram_adr_i(15 downto 13) who's driving them ?
>> 
>> Aurash
>> 
>> Aurelian Lazarut wrote:
>> 
>>> you have a 8K memory but it seems from the log file that you are not 
>>> using the all the address bits,
>>> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
>>> which means that you basically need only 1K from the total of 8K and 
>>> XST remove the rest, I think this make sense if you keep these 
>>> addresses tied to a constant.
>>> Aurash
>
>    Hello Aurash,
>
>thanks for the prompt reply.
>     (the 8KB memory serves as the external RAM of the 8051)
>But 8 KByte uses 13 address bits, so that's ok. The 8051 cpu has 16 
>address bits and only 13 bits for the lower 8 KB are used.
>Or better, the 8KB is repeated 8 times in the 64KB address space.
>So all 13 address lines for the RAM are used, and I don't see why
>it is optimized away.
>
>   Sietse

In your code, I didn't see any decoding of the top 3 bits to enable
one of the 8 rams to cover the whole 64k range. That's the reason it
thinks all the memories are identical, you are using the same 13 bits
to drive them. You should somehow differentiate them, probably with an
enable signal generated from the top 3 bits (maybe you're doing that
during the generation of read/write strobe?). Why it's removing the
last 8k memory I am not sure as you are certainly driving the inputs;
check the top level connectivity for reading the outputs of the memory
into the core.

Article: 104449
Subject: Re: RS232 to access TX registers of Aurora using PPC (EDK)
From: "Vivek Menon" <vivek.menon79@gmail.com>
Date: 27 Jun 2006 12:00:51 -0700
Links: << >>  << T >>  << A >>
Hi,
I am not sure about this and hence the modified question:
After designing the Aurora protocol and implementing it, I want to
access the data values using my PC. For this purpose, I thought of
sending the tx values through the RS232 port of the PowerPC. However, I
am having a problem. I am not able to access the RS232 access ports.
The files are proprietary of XIlinx EDK and cannot be modified...( iam
talking abt "opb_uartlite.vhd" and it's rx and tx versions).
I also tried adding the system.xmp file to my ISE project but it's
useless as no ports are avbl for sending the tx data to the RS 232
block.

What is the easiest way to do accomplish this task?? I also gather that
if this can be figured out, I can in the future access different blocks
written in ISE using PPC and output values on RS232. The values inhaled
from RS232 can be used for further processing using Matlab, etc.

Thanks,
Vivek

Hal Murray wrote:
> >Now the problem I have is that the avbl project in XPS has a rx and tx
> >port (std_logic) and the data I need to send is atleast 16 bits. How do
> >I access or interface the register outputs from Aurora to RS232??
>
> It's fairly easy to make a hack RS-232 transmitter.  It's just
> a shift register preloaded with the data and start/stop bits.
> For 16 bits of data, I'd use a 20 bit shift register - 2 8-bit
> bytes with start and stop bits on each.
>
> You can probably sort out all the LSB/MSB first and inversions
> by reading the specs carefully enough.  It's probably simpler to
> put a scope on the cable to your PC and make it send a known pattern.
>
> You (probably) don't need fancy RS-232 level shifters.  Most RS-232
> receivers will do the right thing if you feed them a 3V CMOS signal.
>
> --
> 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.




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search