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
Hello Russell, I have a model in SystemC and to simulate it with Verilog testbench, i am using a PLI (for VCS). you have mentioned SystemC/Verilog co-simulators, but i have not been able to find any. Does anybody know any such simulators available? Thanks in Advance. regards Varun. "Russell Fredrickson" <russell_fredrickson@hp.com> wrote in message news:<chnpum$vq2$1@news.vcd.hp.com>... > Okay -- I think you (and others who replied) have missed one of the main > points of SystemC. One of the points of SystemC is to enable you to model > and simulate things at a HIGHER level of abstraction than RTL. If you write > code at the RT level -- it will probably always simulate on the same order > of magnitude whether it's Verilog or SystemC -- in fact since the Verilog > simulators are more mature -- Verilog may simulate faster than SystemC > (though I haven't done the exact measurements myself and it is simulator > dependent). The talk about SystemC being faster is making the assumption > that you write SystemC at a higher level of abstraction than your RTL. > Though, as a side note, there are several vendors out there who will > translate Verilog to optimized C/C++ or SystemC and then get about a 10x or > more improvement over Verilog (TenisonEDA and Carbon Systems come to mind). > > In my opinion -- writing RTL in SystemC is a waste of time since Verilog (or > VHDL) is more suitable to that task (and maintaining RTL descriptions in TWO > languages seems like even more of a waste of time and is asking for > trouble). In any case you can always have Verilog and SystemC co-exist by > interfacing SystemC to RTL through a PLI or using one of the unified > SystemC/Verilog simulators. > > My point -- adopting a new language without also adopting a new methodology > that makes use of the power of the language will only give you limited > benefit (if any benefit at all). For example, when going from schematic > capture to Verilog -- many people at first used Verilog just like a textual > schematic capture tool. This got them using an HDL (which is a step in the > write direction), but they really didn't get the full advantage of the HDL > until they started writing RTL that then could then synthesized into gates > (basically raising the level of abstraction at which they modeled their > design). > > So for SystemC some of the power of the language comes in being able to do a > top-down implementation where you start with a high-level architectural > model and refine it down to the RTL level (or perhaps use a behavioral > synthesis tool once you get down to a appropriate level of abstraction). > Also the SystemC Verification extensions (SCV) is another way SystemC can be > used to improve your verification effort (here again -- you will probably > need to use a different verification methodology to make full use of SCVs > capabilities). I'll stop there -- if you look hard enough you should be > able to find other references talking about the new methodologies enabled by > SystemC. > > I hope that helps, > Russell > > > > <singh.shailendra@gmail.com> wrote in message > news:ab4d6621.0409072214.6b8ae5a@posting.google.com... > > Hi, > > Can anybody elaborate on the speed of the simulation in systemC in > > comparision with Verilog. In our case we have used the systemC for > > the modeling of RTL design, then verified the systemC RTL models. As > > a final step > > systemC RTL is converted into verilog RTL(line by line translation). > > we are surprised to see the both systemC models and Verilog models are > > running at almost same speed. Can you through some light on it, what > > went wrong in the process? > > is it systemC coding is not proper or may be testbench not written > > properly or > > if we code systemC and Verilog at same level of abstraction we should > > same speed only.Article: 73001
Hi Subroto,
Thanx for the info.Actually if you are designing only the master
interface for AHB to plug-in to the existing AMBA bus then you are not
very sure that how the internal arbiter is designed(for delayed
HMASTER signal),so can i presume that there will be delayed select
signal for wdata mux and drive both haddr and hwdata on the same clock
or myself should have that addr-data delay??
~~Kumar.
sdatta@altera.com (Subroto Datta) wrote in message news:<ca4d800d.0409091209.3acffdf9@posting.google.com>...
> mmkumar@gmail.com (mack) wrote in message news:<aba94305.0409082246.164990a@posting.google.com>...
> > Hi,
> > I am designing an AMBA-AHB Master interface.As per the spec ,there
> > is a delayed version of the HMASTER bus is used to control the write
> > data mux.So my doubt is ,whether I should have one clk delayed hwdata
> > from haddr or both can be driven at the same time..It's pretty urgent
> > to make up the decision...
> >
> > ~~Kumar.
>
> By definition, AHB has a separate address phase and data phase that is
> to be presented on the bus on two different clocks. Masters are
> responsible for driving those two different phases. In the case where
> there are Muxes controlling what is presented to the rest of the bus,
> you can get away with having a master drive both address and wdata on
> the same clock. In this case, the Muxing scheme that is used must
> insure that the two phases happen when they are supposed to. One way
> to do this is to generate a delayed version of HMASTER from the
> arbiter. The original HMASTER should be the selector for the address
> and control signals and the delayed version should control the mux for
> wdata.
>
> See AN 181 for an example of an AHB bus.
> http://www.altera.com/literature/an/an181.pdf
>
> Hope this helps.
>
> - Subroto Datta
> Altera Corp.
Article: 73002
"Varun Jindal" <varunjindal@yahoo.com> wrote in message
news:a132b4b3.0409092047.6e2980bc@posting.google.com...
> Hello Russell,
>
> I have a model in SystemC and to simulate it with Verilog testbench, i
> am using a PLI (for VCS). you have mentioned SystemC/Verilog
> co-simulators, but i have not been able to find any. Does anybody know
> any such simulators available?
Modelsim, for one: VHDL, verilog, and SystemC (to a limited extent.)
Of course, you need the appropriate licen$e$.
>
> Thanks in Advance.
>
> regards
> Varun.
Jason
Article: 73003Kevin Neilson wrote: > "Simon" <news@gornall.net> wrote in message > news:E240d.141$Mm5.19@newsfe5-gui.ntli.net... > >>I'm trying to do a modular design, building a core, placing it, creating >>an RPM then going on to a sibling or (finally) parent core, doing the >>same, etc. >> >>I've noticed something very odd - it seems the P&R can place, route and >>statically-time a layout which the mapper can subsequently reject with >>'Slice XXYY cannot do X,Y,Z at the same time' errors if it is fed the >>layout as a floorplan. >> >>My main objective has been to see if it's best to lay out on a >>32-clb-high array (with 32-bit carry chains only taking 16 CLB's, for >>example), or to do everything on a 16-CLB-high array and having much >>more depth to the datapath. >> > > Splitting up the carry chains is usually a bad idea. It takes quite a while > to get the signal off the carry chain, and then you have to route it back to > the bottom of the die. I'm sure you're much better off leaving the carry > chain in a single column, and if not, you'd best pipeline the carry. > > RPMs are getting a lot better, but there are still some problems. I find > it's easier to write a Perl script to create a UCF for you using absolute > LOCs. It's kind of a pain, but the tools have no problems with absolute > LOCs. You can write a Perl function that will take a root coordinate and > creat the LOCs for you. Of course you have to rerun this for different > parts or die sizes. The area constraints do work very well. And the placer > sometimes (but not always) yields better results than hand-placement. > -Kevin > > Sorry, not being clear there, the reason I thought a 32-slice tall layout might be a problem is that I didn't want to split the carry chain (which is only 16 slices high). Normally I'd pack the 32-bit datapath into 16 slices and propogate data horizontally across the chip, but the dual-port, 32bit, 32-way register files were taking 5 columns at 16 slices/column - 4 for the distributed RAM and 1 for a (hgh16/low16) mux because there's only 16 bits storage per lut. I have 2 of them to do 2-read,1-write per cycle, so was losing 10 columns just for the register file in the CPU. Other components (shifter for example) were bulky as well, and I was getting close to using all the columns by the time the logic was in place. I wanted an instruction cache and a divider yet to ft in, so I thought I'd try a 32-slice high layout, alternating the per-bit LUTs of each datapath component and fitting 2 components (registers/logic/etc.) per column - that way the propogation is still horizontal in the main. The issue with using 32 slices was carry chains - these fit into 16 slices, and I don't want to break them, so data will have a 'waist' as it routes horizontally across the chip, sort of like: []-[]\ /[] []-[]-[]-[] []-[]/ \[] From my (limited) tests so far, it seems the cpu-16 (ie: fitted into 16 slice-high columns) can run at ~70MHz, but drops to ~50MHz when I wrap the first layer of the SOC around it. The cpu-32 layout starts life at ~56MHz, but only drops to ~53MHz when I wrap the same layer around it. The reason for the speed drop is the same in both cases - routing the wrapper-layer around the RPM is problematic. There are LUTs in the wrapper that connect to LUTs in the cpu all over the shop :-( It seems the tall-and-thin (and presumably with more routing resource to use) 32-slice high variant is more graceful in its degradation, although the real test will come when I wrap the majority of the SOC around this core, with the associated databusses and address bus... Your idea of using absolute LOCs sounds intriguing :-) Definitely bears some study to see how I could get it to work... I'm running in Linux now, so Perl/PHP seem so much more natural to use [grin] Simon.Article: 73004
"apai" <arjunpai23@hotmail.com> writes: > I wanna generate EDIF netlist from Verilog code. I am using Xilinx > ISE6.2i software, and cannot find any trace of EDIF netlist > generated. I don't think XST can generate EDIF anymore. If you want EDIF you need to use a third party synthesis tool like DC-FPGA. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 73005
On 10 Sep 2004 11:00:43 +0200, Petter Gustad <newsmailcomp5@gustad.com> wrote: >"apai" <arjunpai23@hotmail.com> writes: > > >> I wanna generate EDIF netlist from Verilog code. I am using Xilinx >> ISE6.2i software, and cannot find any trace of EDIF netlist >> generated. > >I don't think XST can generate EDIF anymore. If you want EDIF you need >to use a third party synthesis tool like DC-FPGA. XST produces a .ngc file, which can be converted to EDIF with ngc2edif.exe. You can then convert the EDIF to a .ngd file using edif2ngd.exe. (I have noticed discrepancies between the ngc and the edif related to attributes, so beware.) Regards, AllanArticle: 73006
sdatta@altera.com (Subroto Datta) wrote in message news:<ca4d800d.0409091147.f263ae@posting.google.com>... > Hi Andrew, > [snip] > > Hope this helps. > > - Subroto Datta > > Altera Corp. Thanks. Actually, I'm still a bit confused. I've done my PCB board layout on the assumption unused pins are inputs. Most are ground. One or two are tied to +5V for convenience. These MUST be inputs! It seems I have 3 choices with the unused pin setting: 1. Set as reserved input 2. Set as reserved output driving an unspecific signal 3. Leave as default Options 3 sounds a bit risky because you said GND* was the same as 2. So I MUST reserve them as inputs. Correct?Article: 73007
I am having problems simulating fifos with quartus and modelsim.
My environment is set up as follows:
Quartus II v4.1 SP1
Modelsim-Altera 5.8c (with updated sim models)
I was seeing problems on a large design I have, whereby the the data
was not coming out of the fifo when being read.
As this was a large desing I decided to create a new project/design
which contains ONLY a fifo (LMP_FIFO+, single clock) and simulate
that.
I have generated the .vho file for use with Modelsim-Altera and
simulated this with my own testbench.
One thing worth mentioning is that when I start the simulation, I get
a load of warnings from Modelsim:-
** Warning: CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, and it has been converted to 0.
# Time: 0 ps Iteration: 0 Instance:
/fifo_test_tb/fifo_test_i0/fifo_i0/scfifo_component/auto_generated/dpfifo/fiforam/segment_a0_a_a0_a
...this is just because I haven't specified an .init file for the
fifo, but this won't prevent correct operation...will it ! ?
When I bring up the waves I can see the following:-
(i) the clock is running
(ii) reset, devpor, devclrn are all asserted (correct polarity)
at start of the sim and then de-asserted 100 ns later.
(iii) the wr_req is set active, and the data_in has an
incrementing pattern
(iv) valid_wrreq (internal to the LPM_FIFO+ component) is active
as expected
(v) ww_fiforam_wraddress (internal to the LPM_FIFO+ component)
increments as expected
(vi) fifo_usedwd (internal to the LPM_FIFO+ component) increments
as expected
(vii) empty and almost_empty (internal to the LPM_FIFO+ component)
get cancelled as expected
(viii) rd_req is set active
(ix) valid_rdreq (internal to the LPM_FIFO+ component) is active
as expected
(x) ww_fiforam_rdaddress (internal to the LPM_FIFO+ component)
increments as expected
(xi) fifo_usedwd (internal to the LPM_FIFO+ component) freezes
since I am writing and reading at the same rate as expected
(only start read once fifo_usedwd reaches about 12)
(xii) BUT, no data appears at the output port, even though
everything else suggests that the fifo is being operated
correctly !
Can anyone offer any assistance
(I have also submitted a service req to Altera, but on previous
experience am not to confident in the response I 'might' receive)
Any assistance would be very much appreciated
JohnnyNorthener
Article: 73008First of all for FPGAs you should start counting LUTs not gates. A serious problem with questions like these is that it really depends on the quality of the designers that work on the task. Try to google for applications that have many FPGA implementations like AES encryption cores, Java Processors or implementations of legacy processors like 6502 or 8051. You will notice that size and performance vary by a factor of 10 at least. And this is usually not an area/delay tradeoff. In many cases the smaller solution has also the higher performance. Or read this newsgroup: When the dedicated multipliers in virtex-II were announced there where both complaints that these were slower than multipliers implemented in the regular fabric as well as complaints that it were impossible to implement dsp systems with the clock rate claimed by the manufacturer. These clearly came from designers living in different worlds from each other ;-) You really should talk to whoever is going to implement the design for estimates. However, I can give you a first rule of thumb for regular DSP systems (FIR-filters and the like). Assuming that you do not apply any sophisticated transformations to your design like nibble serial operation or the like (which probably you should). The newer architectures from Xilinx and Altera provide you with 18-Bit Multipliers that run around 100Mhz without much effort. Determine how many of these you need and select a chip based on that estimate. Then check wether the internal RAMs are sufficient for you memory architecture (delay lines, coefficients, etc.). You are probably not going to run out of logic ressources for most straigth forward DSP implementations. Kolja Sulimma mwiesbock@microwavetech.com (wiezbox) wrote in message news:<334ff408.0409091024.56ee201@posting.google.com>... > My company is going to start getting into the area of digital signal > processing for one of our projects. FPGAs seem to be what we need, > however I am a little foggy on how many gates to expect we need. Can > someone give an example of how many gates can preform a specific > operation in order to get a little better understanding on the number > I need. > > Thanks!Article: 73009
Hi, We are searching for a simple FPGA board with : * A cPCI interface * Available clock dedicated pin, so we can drive the FPGA with an external 100MHz (or 200MHz) clock. * Some I/O available Is there any manufacturer building such board ? Thank youArticle: 73010
hello friends, I'm a new bee to fpga,, i have one board in that i have spartan II xc2s100 -5tqfp144. ok. that board meant for optics application. i connect that board thru jtag port. I measure that the voltage at TDO = 5V when we plug to the board. And also i check vcco,vccint and gnd of the fpga all are giving voltage perfectly. And the cable also works properly. i want to test and programming the fpga.. After i configure the devices via boundary scan test by inputting the bit files, it tell me the devices and after i program it.. it gives the error as Error : iMPACT : the idcode read from the devices doesn't match the idcode in the bsdl files. please give some suggestion... Regards Senthil.RArticle: 73011
On Fri, 10 Sep 2004 03:38:50 -0700, Ricaud <> wrote: >Hi, > >We are searching for a simple FPGA board with : > >* A cPCI interface >* Available clock dedicated pin, so we can drive the FPGA with an external 100MHz (or 200MHz) clock. >* Some I/O available > >Is there any manufacturer building such board ? > >Thank you There are many vendors with way too many boards. You might want to have a look here: http://www.fpga-faq.com/FPGA_Boards.shtml =================== Philip Freidin philip.freidin@fpga-faq.com Host for WWW.FPGA-FAQ.COMArticle: 73012
"Antti Lukats" <antti@case2000.com> writes: > <Ricaud> wrote in message news:ee886d9.-1@webx.sUN8CHnE... > > Hi, > > > > We are searching for a simple FPGA board with : > > > > * A cPCI interface > > * Available clock dedicated pin, so we can drive the FPGA with an external > 100MHz (or 200MHz) clock. > > * Some I/O available > > > > Is there any manufacturer building such board ? > > quite many > > > memec has PCI board with XC2S200 But the question was regarding compact PCI wasn't it? Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 73013
Hi all, I am in the case where I need to provide large VHDL code to a customer. The design is very large, with some parts written specially for the customer and with some parts coming from our own re-use VHDL code. The application is PCI based with specific data processing, with on board true random number generator modules. The PCI core side is the bigger part of the our own re-use code, and we want to protect it. Now the question is: How to provide the PCI core side to my customer since he cannot (wnat not to) pay for the generic VHDL source code? In an other hand, my customer want (ready to pay) to be able to simulate all design, to be able to modify the specific data processing part (not the PCI part), and to be able to do new Place&Route of all the design. My company cannot pay for a software doing 'crypto' on the VHDL source code with a concerponding core generator. I was thinking to provide to my customer a post-synt model corresponding to a RTL description or post-P&R model for a specific techno like SPARTAN-II (using XST). The trouble with post-synt models is we cannot re-synt. the model for a new P&R version. So, what's the best way (low cost) to generate a RTL IP core (soft-hard core) ? Thanks for advicing me ! LarryArticle: 73014
Yes, we are looking for compact PCI boards. The boards I have seen are etheir too sophisticated (µP, multiple FPGA ...), either not cPCI. Thank you for helpArticle: 73015
Mike wrote:
>
> Another possible solution is to use perl or bash
> to convert the external hex file to a deferred
> constant package body something like:
>
I wrote one of those a few years back; I've attached the
latest version below, along with some sample files:
<test.obj> input object file
<test.vh1> generated package with constant array
<test.vh2> generated package with INITs
<ylink.pl> perl 'linker' that creates VHDL source files
The perl script reads the assembler object file and coughs up
two VHDL files, one a package with a constant array suitable
for simulation or inferred RAM, the other a package with INITs
and generics for instantiated BRAMs.
At the time I wrote this, XST didn't support indexing into a
constant array from within a generate loop; I believe the current
XST version would allow putting the INITs into an array, making
it easier to support BRAM organizations other than the currently
hardcoded 512x32 (four RAMB4_S8_S8's ).
Also, some old posts regarding how to initialize dual port variable
width BRAMs (Harvard architecture, 16 bit instruction, 32 bit data)
are at:
http://groups.yahoo.com/group/fpga-cpu/message/234
http://groups.yahoo.com/group/fpga-cpu/message/332
Other ROM generation programs:
If you download MikeJ's nifty Asteroids emulation, there's a
C++ 8 bit ROM generation utility included <romgen.cpp>.
http://home.freeuk.com/fpgaarcade/ast_main.htm
Mike Butts has a hex2init perl script (more elegant than mine) that
generates a constraints file for 16 bit memories :
http://users.easystreet.com/mbutts/xr16vx_jhdl.html
Also, I believe the newer versions of Xilinx's DATA2MEM utility
will cough up a file with INIT's for primitive simulation as well
as update an existing bitstream with new memory data.
Brian
<test.obj>
@0
opcode=0000011111110000
opcode=0000011111110000
opcode=0000010111110000
opcode=0000010111110000
opcode=0000010111110000
opcode=0000001111110000
opcode=0000001111110000
opcode=0000001111110000
@200
long=12345678
word=abcd
byte=de
byte=ad
byte=be
byte=ef
<test.vh1>
--
-- Auto-generated by ylink.pl
--
library ieee;
use ieee.std_logic_1164.all;
package mem_dat_pkg is
constant MEM_SIZE : natural := 1024;
type mem_type is array (0 to MEM_SIZE-1) of std_logic_vector (15
downto 0);
constant mem_dat : mem_type :=
(
0 => X"07F0",
1 => X"07F0",
2 => X"05F0",
3 => X"05F0",
4 => X"05F0",
5 => X"03F0",
6 => X"03F0",
7 => X"03F0",
256 => X"1234",
257 => X"5678",
258 => X"abcd",
259 => X"dead",
260 => X"beef",
others => ( others => '0')
);
end mem_dat_pkg;
<test.vh2>
--
-- Auto-generated by ylink.pl
--
library ieee;
use ieee.std_logic_1164.all;
package mem_init_pkg is
constant RAM3_INIT_00 : string :=
"0000000000000000000000000000000000000000000000000000000003050507";
constant RAM2_INIT_00 : string :=
"00000000000000000000000000000000000000000000000000000000F0F0F0F0";
constant RAM1_INIT_00 : string :=
"0000000000000000000000000000000000000000000000000000000003030507";
constant RAM0_INIT_00 : string :=
"00000000000000000000000000000000000000000000000000000000F0F0F0F0";
constant RAM3_BV_INIT_00 : bit_vector :=
X"0000000000000000000000000000000000000000000000000000000003050507";
constant RAM2_BV_INIT_00 : bit_vector :=
X"00000000000000000000000000000000000000000000000000000000F0F0F0F0";
constant RAM1_BV_INIT_00 : bit_vector :=
X"0000000000000000000000000000000000000000000000000000000003030507";
constant RAM0_BV_INIT_00 : bit_vector :=
X"00000000000000000000000000000000000000000000000000000000F0F0F0F0";
<snip>
constant RAM3_INIT_04 : string :=
"0000000000000000000000000000000000000000000000000000000000beab12";
constant RAM2_INIT_04 : string :=
"0000000000000000000000000000000000000000000000000000000000efcd34";
constant RAM1_INIT_04 : string :=
"000000000000000000000000000000000000000000000000000000000000de56";
constant RAM0_INIT_04 : string :=
"000000000000000000000000000000000000000000000000000000000000ad78";
constant RAM3_BV_INIT_04 : bit_vector :=
X"0000000000000000000000000000000000000000000000000000000000beab12";
constant RAM2_BV_INIT_04 : bit_vector :=
X"0000000000000000000000000000000000000000000000000000000000efcd34";
constant RAM1_BV_INIT_04 : bit_vector :=
X"000000000000000000000000000000000000000000000000000000000000de56";
constant RAM0_BV_INIT_04 : bit_vector :=
X"000000000000000000000000000000000000000000000000000000000000ad78";
<snip>
constant RAM3_INIT_0F : string :=
"0000000000000000000000000000000000000000000000000000000000000000";
constant RAM2_INIT_0F : string :=
"0000000000000000000000000000000000000000000000000000000000000000";
constant RAM1_INIT_0F : string :=
"0000000000000000000000000000000000000000000000000000000000000000";
constant RAM0_INIT_0F : string :=
"0000000000000000000000000000000000000000000000000000000000000000";
constant RAM3_BV_INIT_0F : bit_vector :=
X"0000000000000000000000000000000000000000000000000000000000000000";
constant RAM2_BV_INIT_0F : bit_vector :=
X"0000000000000000000000000000000000000000000000000000000000000000";
constant RAM1_BV_INIT_0F : bit_vector :=
X"0000000000000000000000000000000000000000000000000000000000000000";
constant RAM0_BV_INIT_0F : bit_vector :=
X"0000000000000000000000000000000000000000000000000000000000000000";
end mem_init_pkg;
<ylink.pl>
#! /usr/local/bin/perl5
#-------------------------------------------------------------------------------
# YARD-1 Linker v0.01
#-------------------------------------------------------------------------------
#-------------------------------------------------------------------------------
#
# ylink.pl v0.01 (C) COPYRIGHT 2001 B. Davis
#
# This program is free software; you may use, modify, and
# redistribute it without restriction provided that:
# 1) this header is preserved on all copies
# 2) any modified versions are clearly identified as such
#
# Being free software, this program comes with neither support
# nor warranty, including any implied warranty of merchantability
# or fitness for a particular purpose.
#
#-------------------------------------------------------------------------------
#-------------------------------------------------------------------------------
#
# General Notes:
#
# - reads .obj file generated by yasm.pl
# - writes VHDL file with INIT_XX constants
#
# currently, more of a memory image generator than a real linker
#
# - linker output files:
# - <file>.vh2 = VHDL file with INIT_XX constants
# - <file>.vh1 = VHDL file with constant array holding memory
data
# - <file>.cmd = YARDBUG command file to load program
#
#
#-------------------------------------------------------------------------------
#-------------------------------------------------------------------------------
#
# 'to do' list:
#
#
# - add command line args for:
# - memory image start/size
# - block RAM organization ( generate different INIT_XX records
as needed )
# - VHDL output file name and/or package name in VHDL file
#
# - add other output formats:
# - S-record or similar hex format
# - EPIC command script for editing block RAM
# - .coe for COREGEN created memories
#
#
#-------------------------------------------------------------------------------
#-------------------------------------------------------------------------------
#
# history:
#
# Nov. 2001
# - moved VHDL constant array file (.vh1) generation here from
yasm.pl
#
# Jul. 2001
# - added bit vector INIT's for simulation generics ( instead of
writing VHDL xlate function )
#
# Mar. 2001
# - changed memory image and INIT code to use byte array instead of
word array
#
# Feb. 2001
# - created
#
#
#
#-------------------------------------------------------------------------------
printf("\nYARD-1 Linker Version 0.01\n");
# should have one argument, the object file
if ($#ARGV != 0) { die ("\nError: Expecting one (and only one) object
file \n") };
$obj = $ARGV[0];
$obj =~ s/\.obj$//g;
$obj_file = $obj . '.obj';
$cmd_file = $obj . '.cmd';
$vho_file = $obj . '.vh2';
$vhc_file = $obj . '.vh1';
open (OBJ_F, "$obj_file") or die ("Can't open $obj_file: $!\n");
open (CMD_F, ">$cmd_file") or die ("Can't open $cmd_file: $!\n");
open (VHO_F, ">$vho_file") or die ("Can't open $vho_file: $!\n");
open (VHC_F, ">$vhc_file") or die ("Can't open $vhc_file: $!\n");
#
# vhdl INIT output file header/trailer
#
$vho_file_header = "--
-- Auto-generated by ylink.pl
--
library ieee;
use ieee.std_logic_1164.all;
package mem_init_pkg is
";
$vho_file_trailer = "
end mem_init_pkg;
";
#
# vhdl constant array output file header/trailer
#
$vhc_file_header = "--
-- Auto-generated by ylink.pl
--
library ieee;
use ieee.std_logic_1164.all;
package mem_dat_pkg is
constant MEM_SIZE : natural := 1024;
type mem_type is array (0 to MEM_SIZE-1) of std_logic_vector (15
downto 0);
constant mem_dat : mem_type :=
(
";
$vhc_file_trailer = "
others => ( others => '0')
);
end mem_dat_pkg;
";
# $D1 turns debug prints on/off
$D1 = 0;
#
# memory array definitions ( for INIT_XX attribute calculation )
# currently hardcoded for a 2K byte RAM starting at zero
# indexed by bytes
# values stored as two digit hex string
#
$mem_init_value = "XX";
$mem_start = 0;
$mem_size = 2048;
#
# initialize memory image array
#
$mem_data[$mem_size-1] = $mem_init_value;
for($i=0 ; $i < $mem_size; $i++ ) { $mem_data[$i] = $mem_init_value;}
# clear other flags
$error = 0;
#
# Read .obj file, build memory image
#
while ($line = <OBJ_F>)
{
chop $line;
if ($line =~ /@(.+)/)
{
$address = oct ( "0x" . $1 );
}
elsif ($line =~ /opcode=(\d{16})$/)
{
$op16 = vec(pack("B16", $1),0,16);
$dat_str = sprintf "%04X", $op16;
$mem_data[ $address - $mem_start ] =
substr($dat_str,0,2);
$mem_data[ $address - $mem_start + 1 ] =
substr($dat_str,2,2);
$address = $address + 2;
}
elsif ($line =~ /byte=(.{2})$/)
{
$mem_data[ $address - $mem_start ] = $1;
$address = $address + 1;
}
elsif($line =~ /word=(.{4})$/)
{
$mem_data[ $address - $mem_start ] = substr($1,0,2);
$mem_data[ $address - $mem_start + 1 ] = substr($1,2,2);
$address = $address + 2;
}
elsif($line =~ /long=(.{8})$/)
{
$dat_str = substr($1,0,2);
$mem_data[ $address - $mem_start ] = $dat_str;
$dat_str = substr($1,2,2);
$mem_data[ $address - $mem_start + 1 ] = $dat_str;
$dat_str = substr($1,4,2);
$mem_data[ $address - $mem_start + 2 ] = $dat_str;
$dat_str = substr($1,6,2);
$mem_data[ $address - $mem_start + 3 ] = $dat_str;
$address = $address + 4;
}
} # end while
#
# Write YARDBUG command file
#
$c_start = -1;
for($i=0 ; $i < $mem_size; $i++ )
{
if ( $c_start == -1)
{
if ( $mem_data[$i] ne "XX" )
{
$c_start = $i;
printf CMD_F ("M %08X %s ", $i,$mem_data[$i] );
}
}
else
{
if ( $mem_data[$i] ne "XX" )
{
printf CMD_F ("%s ", $mem_data[$i]);
}
if ( ( $mem_data[$i] eq "XX" ) || ( $i >= ($c_start + 15) ) )
{
$c_start = -1;
printf CMD_F ("\n" );
}
}
}
printf CMD_F ("\n" );
#
# Write VHDL constant array file
#
# create output file boilerplate
print VHC_F $vhc_file_header;
# dump memory values to VHDL word array ( dumps only word locations
being used )
for($i=0 ; $i < $mem_size; $i+=2 )
{
if ( ( $mem_data[$i] ne "XX" ) || ( $mem_data[$i+1] ne "XX" ) )
{
printf VHC_F (" %12d => X\"%s%s\", \n", $i >> 1,
$mem_data[$i], $mem_data[$i+1] );
}
}
# VHDL boilerplate to end memory array
print VHC_F $vhc_file_trailer;
#
# fill unused locations with zeroes before calculating INIT strings
#
for($i=0 ; $i < $mem_size; $i++ )
{
if ( $mem_data[$i] eq "XX" )
{
$mem_data[$i] = "00";
}
}
#
# Write VHDL blockram init file
#
# create output file boilerplate
print VHO_F $vho_file_header;
#
# spit out INIT_XX strings
# - currently hardcoded to read a 2K x 8 memory image array
# - writes INIT's for a 512 x 32 block RAM built from four
RAMB4_S8_S8's
#
$init_blks = 16;
$init_blk_size = 32;
$init_str_size = 64;
for ( $i=0 ; $i < $init_blks; $i++ ) # INIT_00 through INIT_0F
{
for ( $j=0 ; $j < $init_blk_size; $j++ ) # 32 longs (32 bit) per
INIT block
{
# two hex chars. per word for each x8 BRAM; LSB value = last
char in string
$str_index = $init_str_size - ( $j*2 ) - 1;
# byte address in memory array
$baddr = ( $i * $init_blk_size * 4 ) + ( $j * 4 );
$s3[$str_index-1] = substr($mem_data[$baddr], 0, 1);
$s3[$str_index] = substr($mem_data[$baddr], 1, 1);
$s2[$str_index-1] = substr($mem_data[$baddr+1], 0, 1);
$s2[$str_index] = substr($mem_data[$baddr+1], 1, 1);
$s1[$str_index-1] = substr($mem_data[$baddr+2], 0, 1);
$s1[$str_index] = substr($mem_data[$baddr+2], 1, 1);
$s0[$str_index-1] = substr($mem_data[$baddr+3], 0, 1);
$s0[$str_index] = substr($mem_data[$baddr+3], 1, 1);
if ($D1) { printf ("INIT: %d %d %d %d %s %s\n", $i, $j,
$str_index, $baddr, $mem_data[$baddr],$mem_data[$baddr+1] ); }
if ($D1) { printf ("INIT: %d %d %d %d %s %s\n", $i, $j,
$str_index-1, $baddr+1, $mem_data[$baddr+2], $mem_data[$baddr+3] ); }
}
printf VHO_F ("constant RAM3_INIT_%02X : string :=
\"%s\";\n", $i, join('', @s3) );
printf VHO_F ("constant RAM2_INIT_%02X : string :=
\"%s\";\n", $i, join('', @s2) );
printf VHO_F ("constant RAM1_INIT_%02X : string :=
\"%s\";\n", $i, join('', @s1) );
printf VHO_F ("constant RAM0_INIT_%02X : string :=
\"%s\";\n", $i, join('', @s0) );
printf VHO_F ("\n");
printf VHO_F ("constant RAM3_BV_INIT_%02X : bit_vector :=
X\"%s\";\n", $i, join('', @s3) );
printf VHO_F ("constant RAM2_BV_INIT_%02X : bit_vector :=
X\"%s\";\n", $i, join('', @s2) );
printf VHO_F ("constant RAM1_BV_INIT_%02X : bit_vector :=
X\"%s\";\n", $i, join('', @s1) );
printf VHO_F ("constant RAM0_BV_INIT_%02X : bit_vector :=
X\"%s\";\n", $i, join('', @s0) );
printf VHO_F ("\n");
}
# finish up output file boilerplate
print VHO_F $vho_file_trailer;
# tidy up
close OBJ_F;
close CMD_F;
close VHO_F;
close VHC_F;
printf("\nTotal Errors = %d\n", $error);
Article: 73016> I was thinking to provide to my customer a post-synt model corresponding > to a RTL description or post-P&R model for a specific techno like > SPARTAN-II (using XST). The trouble with post-synt models is we cannot > re-synt. the model for a new P&R version. > > So, what's the best way (low cost) to generate a RTL IP core (soft-hard > core) ? > > Thanks for advicing me ! > > Larry I found my solution : using "IP (CoreGen & Architecture Wizard)" in the Xilinx ISE 6.0 . I have newer seen this ISE option before. Anyway, this will be my solution for generating soft-hard IP.Article: 73017
Hello Larry, With respect to the simulation aspect of your question, I believe that most simulators have a feature which would allow you to compile your core into a library in such a way that there is no associated source code. Then your customer may simply instantiate the core and use it for simulation. With regards to the physical implementation, you could provide them the output file (for example EDIF) of the synthesizer. Typically this is RTL in nature. However you need to realize that this is not going to protect your design. For example if your core is versatile, well defined, not buggy, and independent of the rest of the design there is nothing to stop them from using it in other designs of theirs! Regards, CarltonArticle: 73018
John, I replied to you directly on this already this AM, but for the benefit of the newsgroup, I will also reply in shorter fashion here. The DCM is all digital. If a clock edge is missing, nothing happens. But, if the clock edge comes back at exactly the right time later (not too much later, as if temperature of voltage changes, then the delay of the delay line changes), then the DCM picks up where it left off. If the clock edge comes back while other clock edges are already in the delay line, then it has to be in the right phase relationship or the DCM will either loose lock, or shift in phase (try to track the new edge because it gets confused). In a clock switch, phase is usually unknown, and often the frequency is slewing as well. Not to mention distorted periods, bad duty cycles, etc. When switching clocks, always reset the DCM after the clock is stable again after the switch. Austin John Cappello wrote: > Austin, > > Thanks for the insight on the duty cycle. We will check this. One more > thing. What can we expect from the integrity of a DCM in a system > where it is common to switch clock sources or clock frequencies? We > have found that the DCM does not lose lock or indicate "clkin_stopped" > during these sequences. > > Are we supposed to reset the DCM after such an occurrence? If so, we > are trying to figure out how we will know to do this since the DCM > doesn't unlock or indicate that the input clock has stopped. > > The DCM spec states (in the "Input Clock Changes" section) that the > DCM can tolerate pauses or phase shifts in the clock, but later on in > the spec, states "once locked to a frequency, cannot tolerate large > variations of the input frequency." Exactly what is meant by "cannot > tolerate"? Does this mean that it is possible for the DCM to offset > its "phase shift" on the output clock from the optimal setting? > > Thanks! > John > > > Austin Lesea <austin@xilinx.com> wrote in message news:<chprct$73l1@cliff.xsj.xilinx.com>... > >>John, >> >>There have been cases where the frequency, jitter, and duty cycle are >>just on the edge of where the DCM phase detector will operate reliably. >> >>Check the input duty cycle. It will need to be as close to 50% as you >>can make it. The spec is 45 to 55%, but at the higher frequencies, it >>may have to be even closer to 50% when you take clock jitter into >>account (as if it is 45%, and it has jitter, then it is sometimes less >>than 45%!). >> >>Hope this helps. >> >>If you can vary the input clock duty cycle, you should be able to make >>it always work, never work, and be in between like it is now. That will >>show you where it needs to be. >> >>Duty cycle management is a tough thing as it is affected by signal >>integrity, and at 311 MHz, signals get distorted very easily. >> >>Even observing the signal can be tough, as it doesn't look like it does >>on the die at the pins (just simulate it to see that). >> >>In the past, I have seen cases where the 100 ohm LVDS receive >>termination is removed, and the problem goes away (due to the location >>of the 100 ohm resistor, and the stubs causing reflections distorting >>the signal). The termination for a clock signal input isn't really >>required (would be for a data signal to prevent ISI). >> >>Subsequent versions of the DCM (S3 and V4) have even better phase >>detectors which are more tolerant of the duty cycle. Always room for >>improvements. >> >>Austin >> >>John Cappello wrote: >> >> >>>Hi, >>> >>>We are seeing evidence that a DCM is intermittently selecting the >>>wrong tap position after it completes its lock sequence after a DCM >>>reset pulse. I'd like to know if anyone has experienced this effect, >>>and if they were able to resolve this problem. >>> >>>In a 2v6000, I am using a variable phase shift DCM which is driven by >>>a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz clocks >>>on its clk0/clk180 output pins. This interface uses IOB DDR regs for a >>>622 Mhz/16-bit LVDS transmission solution. >>> >>>The DCM initial value is set to 0. After a DCM reset, the DCM is phase >>>shifted to its predetermined optimal "error-free" setting. However, >>>intermittently, the interface experiences a small amount of bit >>>errors. >>> >>>To eliminate the errors, the DCM is further phase shifted in one >>>direction until it actually achieves error-free operation. The >>>subsequent error-free window of operation in this mode matches very >>>closely to the original calibration error-free window. >>> >>>It is as if the DCM locking sequence is corrupted somehow, resulting >>>in a mis-aligned tap position. We don't have conclusive evidence >>>because we can't see inside the DCM to see its tap position. We have >>>found that we can eliminate this error condition by applying another >>>one or two reset pulses to the DCM. >>> >>>I realize that voltage fluctuations and switching noise could be >>>causing this effect. Nonetheless, I'd like to hear from real world >>>experiences. >>> >>>Thank you. >>>JohnArticle: 73019
ERROR:HDLParsers:3014 - d:/xilinx/8051/mc8051_rom_.vhd Line 68. Library unit std_logic_textio is not available in library IEEE. there is no such library in Xilinx webpack?? Where can i found it??Article: 73020
Looks like the main improvement over VirtexIIpro is the reduction in time to get on and off the carry chain. Tbyp is 88ps = 44ps/bit in the slowest VIIpro. But the time on and off the chain, e.g. Topcyf is about twice as quick in the V4, saving c.400ps meaning you get more than 16 bits longer a counter at the same speed. Cheers, Syms. "Philip Freidin" <philip@fliptronics.com> wrote in message news:ib5ij056k378e2m6ot9kc75gr2cr9nkmt0@4ax.com... > > > Looks like a 32 bit counter hits 360 MHz, in a -11, with preliminary > speed files. Gotta love the 41.5 ps/bit carry chain. > >> > Philip > > Philip Freidin > FliptronicsArticle: 73021
I'm currently running SuSE Linux SLES8 AMD64, and ISE 6.2 works fine. I'm planning to upgrade to SuSE Linux 9.1 and was wondering if there are reports of the Xilinx tools working there. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."Article: 73022
Hi, Anyone who wants to start(beginers) working on PCI, USB can have a look at Altera's MAX II Development Kit(they also supply some pci and usb reference designs). This is the lowest pci usb combo board that i have seen. Any way it's worth to have a look. http://www.altera.com/products/devkits/altera/kit-maxii-1270.html -raoArticle: 73023
The one we are using is the Cadence Insicive Unified Simulator. I know
Mentor has a version as well (don't know about Synopsys). I don't know
about the Mentor version -- but The Cadence implementation is very nice in
that you can do things like call Verilog functions/tasks from SystemC (and
in the next version -- IUS 5.4 -- you are supposed to be able to call
SystemC functions from Verilog), instantiate SystemC inside Verilog (and
vice versa), directly access Verilog memories from SystemC, etc. In
addition, they do have an integrated environment debug environment and a
good transaction recording facility (from what I can tell -- I haven't used
the transaction recording too much yet). Cadence also has it's hands in
donating major portions of the SystemC add on libraries (SCV, TLM
methodology) -- so they really good in terms of full support for most
anything you want to do with SystemC. Again, I really don't have any data
on Mentor's version, so I can't comment on it.
Russell
"Varun Jindal" <varunjindal@yahoo.com> wrote in message
news:a132b4b3.0409092047.6e2980bc@posting.google.com...
> Hello Russell,
>
> I have a model in SystemC and to simulate it with Verilog testbench, i
> am using a PLI (for VCS). you have mentioned SystemC/Verilog
> co-simulators, but i have not been able to find any. Does anybody know
> any such simulators available?
>
> Thanks in Advance.
>
> regards
> Varun.
>
>
>
>
>
> "Russell Fredrickson" <russell_fredrickson@hp.com> wrote in message
news:<chnpum$vq2$1@news.vcd.hp.com>...
> > Okay -- I think you (and others who replied) have missed one of the main
> > points of SystemC. One of the points of SystemC is to enable you to
model
> > and simulate things at a HIGHER level of abstraction than RTL. If you
write
> > code at the RT level -- it will probably always simulate on the same
order
> > of magnitude whether it's Verilog or SystemC -- in fact since the
Verilog
> > simulators are more mature -- Verilog may simulate faster than SystemC
> > (though I haven't done the exact measurements myself and it is simulator
> > dependent). The talk about SystemC being faster is making the
assumption
> > that you write SystemC at a higher level of abstraction than your RTL.
> > Though, as a side note, there are several vendors out there who will
> > translate Verilog to optimized C/C++ or SystemC and then get about a 10x
or
> > more improvement over Verilog (TenisonEDA and Carbon Systems come to
mind).
> >
> > In my opinion -- writing RTL in SystemC is a waste of time since Verilog
(or
> > VHDL) is more suitable to that task (and maintaining RTL descriptions in
TWO
> > languages seems like even more of a waste of time and is asking for
> > trouble). In any case you can always have Verilog and SystemC co-exist
by
> > interfacing SystemC to RTL through a PLI or using one of the unified
> > SystemC/Verilog simulators.
> >
> > My point -- adopting a new language without also adopting a new
methodology
> > that makes use of the power of the language will only give you limited
> > benefit (if any benefit at all). For example, when going from schematic
> > capture to Verilog -- many people at first used Verilog just like a
textual
> > schematic capture tool. This got them using an HDL (which is a step in
the
> > write direction), but they really didn't get the full advantage of the
HDL
> > until they started writing RTL that then could then synthesized into
gates
> > (basically raising the level of abstraction at which they modeled their
> > design).
> >
> > So for SystemC some of the power of the language comes in being able to
do a
> > top-down implementation where you start with a high-level architectural
> > model and refine it down to the RTL level (or perhaps use a behavioral
> > synthesis tool once you get down to a appropriate level of abstraction).
> > Also the SystemC Verification extensions (SCV) is another way SystemC
can be
> > used to improve your verification effort (here again -- you will
probably
> > need to use a different verification methodology to make full use of
SCVs
> > capabilities). I'll stop there -- if you look hard enough you should be
> > able to find other references talking about the new methodologies
enabled by
> > SystemC.
> >
> > I hope that helps,
> > Russell
> >
> >
> >
> > <singh.shailendra@gmail.com> wrote in message
> > news:ab4d6621.0409072214.6b8ae5a@posting.google.com...
> > > Hi,
> > > Can anybody elaborate on the speed of the simulation in systemC in
> > > comparision with Verilog. In our case we have used the systemC for
> > > the modeling of RTL design, then verified the systemC RTL models. As
> > > a final step
> > > systemC RTL is converted into verilog RTL(line by line translation).
> > > we are surprised to see the both systemC models and Verilog models are
> > > running at almost same speed. Can you through some light on it, what
> > > went wrong in the process?
> > > is it systemC coding is not proper or may be testbench not written
> > > properly or
> > > if we code systemC and Verilog at same level of abstraction we should
> > > same speed only.
Article: 73024Stephen Williams wrote: > > I'm currently running SuSE Linux SLES8 AMD64, and ISE 6.2 works > fine. I'm planning to upgrade to SuSE Linux 9.1 and was wondering > if there are reports of the Xilinx tools working there. I did some googling and found some hints that LD_ASSUME_KERNEL=2.4.1 is required on SuSE 9.1 and also some newer RedHat releases. Can anyone confirm that will do the trick? On AMD64? -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."
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