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
rickman wrote: > Ray, > > I would like to draw on your experience if I can. I am looking at doing > a SDRAM and SBSRAM interface in an XC2SE chip and would like to get an > idea of what speed grade I will need. Turns out that the DSP chip will > only support up to 100 MHz on the memory bus so I won't have to push the > speed much. Will this be easy on the slowest speed grade which seems to > be a -6? Since there only seem to be two speed grades at this time, I > don't expect to see that much difference (and no industrial in the -7). > I can't tell from the data sheet as it does not have data for the -7 yet > (even though I can buy the parts). > > From your experience will a 100 MHz SDRAM interface be easy in a > XC2S200E-6 ? > Rickman, If I might give my experience - I've got 100MHz working in an XCV600E-6 with only the auto P&R tools and (almost) purely synthesised logic - only a couple of places where I've had to instantiate MUXF5s + a lot of ``syn_keep'' constraints to tell Synplify what to do. For us low latency is vital, latency from our MIPS CPU's start of cycle strobe to the first read dataum back at the CPU is 10 clocks. To put this into context the best latency I've seen for an ASIC controller is 9. If the SpartanIIE timing is the same as the original Virtex-E its doable but not easy without floorplanning esp. if the device useage is high. I'm now pushing on to the 133MHz goal in a -7, I've been keeping floorplanning in reserve for this.Article: 39726
Did you use the Celoxica software with Handel-C? I always thought it produced EDIF instead of VHDL output. cheers, Seb "z.karim" <z.karim@attbi.com> wrote in message news:DyGb8.74623$Pz4.345996@rwcrnsc53... > Formal verification is generally used to verify gate level netlists > are equivalent and is used when designing ASICs. I think of > formal verification at the HDL level as doing simulation equivalence > checks. If you are converting an algorithm written for a CPU to a > hardware algorithm, I would look at the size of the design as the > determining factor. As for all projects, budget, schedule, manpower > all are taken into consideration. > > If the algorithm is large and you can afford to purchase a > software package like Handel-C, I would go for it. It is a cost effective > way of getting what you need. It does have the capability of spitting > out VHDL so you can simulate your result; don't expect to be able > decipher what hardware was generated by looking at the VHDL code. > The one nice thing we noticed using the Handel-C was that we > could do a heck of a lot more architecture modifications in the same > amount of time it would have taken in VHDL. Also, we were able to > convert the ANSI-C to Handel-C in 1/30th the time it took to go to VHDL. > > As far as determining what speed at which the design runs, > you have to place and route the design immediately to get the speed at > which it will run. Handel-C has all the constructs to allow you to dictate > the architecture; it just takes a couple days to get the feel for how it > generates hardware. I have used it and have been happy with the > results: easily passing 100MHz in Spartan II and 200MHz in Virtex II. > > We have used SystemC before also, but just for modeling and not > for hardware generation. It was simple to use also, but we didn't want > to buy the synthesizers from Adelante or Synopsys. Again though, it > was a heck of a lot easier converting the C algorithms to usable > code rather than converting it to VHDL. > > good luck > > "Phil Hays" <spampostmaster@attbi.com.com> wrote in message > news:3C6EA440.ED3E96D3@attbi.com.com... > > > > My current employer has an application where I might want to use one of > the "C > > for hardware" type languages. Basically, there is a sizable chunk of > ANSI-C > > code that might need to be put into hardware to improve system > performance. > > Before this needs to be started, and it is not clear yet if it truly does > need > > to be done, I'd like to learn more. Methods for doing this might might be > to > > convert this C code into hardware-c (Handel-C or System-C), or to hand > convert > > the C into VHDL, and then verify the conversion by simulation (read lots > of > > effort) or to hand convert the C into VHDL and then verify the conversion > by > > some "formal verification" method. > > > > The first alternative brings up a bunch of issues. The tools are fairly > new: it > > seems slightly unlikely to me that "pushing the envelope" type hardware > could be > > built. Is this true? I sat in a Celoxica sales pitch, and the examples > given > > were running at 40 MHz or so. Sorry, but that's not impressive: the parts > can > > easily do 66MHz+ with very little detailed effort, with a high level VHDL > (or > > Verilog) design and almost push-button flow, and 133Mhz, while it does > take more > > effort just isn't that hard. The tools don't appear have features needed > to > > push the design to higher speeds, such as a schematic viewer to quickly > answer > > the question, what did my code build into? I don't know what sort of > support in > > any of the "hardware-C" tools for physical design, is there any? The > users (me > > for example) don't understand the whole process: I can read C and > eventually > > understand what it's doing, I've written some C code, but I don't have > > experience in translating ANSI-C into hardware-C or in writing hardware C. > How > > hard is this to learn? How hard is this to learn to do well? Meaning how > hard > > is it to produce close to minimum sized hardware that runs fast? > > > > Then there is the question of the different variations of hardware-C. > Opinions > > on which is best? (Cue in the VHDL vs Verilog flame war part 2) > > > > The second alternative I understand how to do, it is just work, and there > is > > absolutely nothing wrong with that if it's the best option, yet I'd rather > do it > > faster and easier, or faster and fewer bugs... > > > > The third alternative is formal verification. I have no experience in > such > > tools, so does anyone have experience, opinions (or both) on the question > of > > would this help to produce FPGA hardware that matches the original C? > > > > > > -- > > Phil Hays > >Article: 39727
Thanks for the insight. My design is not connecting a micro to the RAM, it is a DMA controller from IO devices to/from SDRAM. So the latency is not as large of an issue. I will be moving data in blocks of at least 8 words and maybe as many as 32, so the latency won't be a huge impact on the total bus usage time. I will want to minimize the time the DSP is kicked off the bus to transfer blocks. Otherwise, it is not an issue. This is working with a 150 MHz DSP and I was surprized to find that the external memory interface will only run up to 100 MHz. I was looking at using 133 or 150 MHz memory. I guess I will be able to use the cheap stuff. I have worked with SDRAM before, but we were only running at 33 MHz (PCI bus speed). That was an XC4000XL IIRC. 33 MHz was no problem and the rest of the circuit running at 50 MHz was no problem. I did basic floorplanning for the large blocks (mux/demux, FIFO, memory interface) and it worked without problems. There was one place where I was muxing a clock through the chip (not used internally) and I needed a very fast route from the CLB to the IOB next to it. The software could not seen the find the optimal route and I always had to hand route that one path to save that extra half nS. It acutally was not too bad. The chip editor was pretty easy to use and there were never any other signals in the way. Based on what you are saying, I expect with a little floorplanning I should have no trouble at 100 MHz. Thanks. Rick Filipkiewicz wrote: > > rickman wrote: > > > Ray, > > > > I would like to draw on your experience if I can. I am looking at doing > > a SDRAM and SBSRAM interface in an XC2SE chip and would like to get an > > idea of what speed grade I will need. Turns out that the DSP chip will > > only support up to 100 MHz on the memory bus so I won't have to push the > > speed much. Will this be easy on the slowest speed grade which seems to > > be a -6? Since there only seem to be two speed grades at this time, I > > don't expect to see that much difference (and no industrial in the -7). > > I can't tell from the data sheet as it does not have data for the -7 yet > > (even though I can buy the parts). > > > > From your experience will a 100 MHz SDRAM interface be easy in a > > XC2S200E-6 ? > > > > Rickman, > > If I might give my experience - > > I've got 100MHz working in an XCV600E-6 with only the auto P&R tools and (almost) purely > synthesised logic - only a couple of places where I've had to instantiate MUXF5s + a lot > of ``syn_keep'' constraints to tell Synplify what to do. For us low latency is vital, > latency from our MIPS CPU's start of cycle strobe to the first read dataum back at the > CPU is 10 clocks. To put this into context the best latency I've seen for an ASIC > controller is 9. If the SpartanIIE timing is the same as the original Virtex-E its > doable but not easy without floorplanning esp. if the device useage is high. > > I'm now pushing on to the 133MHz goal in a -7, I've been keeping floorplanning in > reserve for this. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 39728
Hi, Can anyone give me advice on how to improve my clock speed in my design. I am using timing constraints before you ask!!. The chip is a Virtex2000E and I am using synplify and the latest Xilinx PAR (ise 4.1etc). The delays in my design appear to be caused by a few long nets (fan out 1 etc). There is lots of free space on the chip so this is not a problem. My target speed is 6.25ns period and the best I can get to is 7ns etc with par effort at maximum. I have tried re-entrant routing with no success. The design is still being updated and added to so can anyone tell me how I can get better par in general ? I would imagine that manual placement would give me better results in theory but then each time i changed the design I would have to repeat this process?? Help! Cheers CraigArticle: 39729
Do I need to install any driver or software in order to use Multilinx? Where can I find a driver for Multilinx, if it has one... -- Best Regards, Qijun. ******************************************************************** Xu Qijun Design Engineer, RFIC Group OKI Techno Centre (S) Pte Ltd 20 Science Park Rd, #02-06/10 Teletech Park,Science Park II, Singapore 117674 DID: 7707049 Fax: 7792382Article: 39730
Maybe until now I did not understand many important things, for example I've the famous BlockRAM CORE v. 4.0 for it I choose to use the negative front 'cause I use it in all the rest of my circuit, the results in terms of speed are ok, almost 100MHz on XCV1K-4 but in term of simulation the result is really bad, it is : # : WARNING: */RAMB4_S1 SETUP High VIOLATION ON ADDR(8) WITH RESPECT TO CLK; # : Expected := 0.01 ns; Observed := 0 ns; At : 1275 ns # : Time: 1275 ns, Iteration: 3, Instance: /U1/U2/U2/B13. # : WARNING: */RAMB4_S1 SETUP Low VIOLATION ON ADDR(7) WITH RESPECT TO CLK; # : Expected := 0.01 ns; Observed := 0 ns; At : 1275 ns # : Time: 1275 ns, Iteration: 3, Instance: /U1/U2/U2/B13. and really many other similar warnings, but let's try to understand what the error say, the problem is that the clock and the address change on the same time while from data_sheets seems that the address must arrive a little bit before 0.01ns. The only rimedy I know is to change the operating edge of the ram so now the address change on negative edge of the clock and the ram work on positive edge. Now the simulation it's ok but the speed on FPGA is reduced to 45MHz. Naturally I need 100MHz and a simulation working fine, it is possible to obtain this ??Article: 39731
With Aldec I arrange the following RAM structure based on twelve
RAMB4S1, the simulation it's ok,
but when I use this file in Xilinx I've the following error from
ModelSim :
# ERROR: Could not open library virtex at virtex: No such file or
directory
# ERROR: RAM_12x4096.vhd(27): Library virtex not found.
OK, I'll try to survive infact XST arrange a black box for it and then
at the end of the
implementation I can see used the RAMB4S1, the problem is that it does
not take the initialization
values so I've zeros in any location. Can you help me to find the
errors and possibly maintaining
the possibility to simulate the project in Aldec ?
Here's the memory structure :
---------------------------------------------------------------------------------------------------
-- Design unit header --
library IEEE;
use IEEE.std_logic_1164.all;
-- other libraries declarations
-- synopsys translate_off
library VIRTEX;
library IEEE;
use IEEE.vital_timing.all;
-- synopsys translate_on
entity RAm is
port(
clk : in std_ulogic;
ADDR : in STD_LOGIC_VECTOR(11 downto 0);
dout : out STD_LOGIC_VECTOR(11 downto 0)
);
end RAm;
architecture RAm of RAm is
---- Component declarations -----
component RAMB4_S1
-- synopsys translate_off
generic(
INIT_00 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_01 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_02 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_03 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_04 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_05 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_06 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_07 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_08 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_09 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_0A : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_0B : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_0C : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_0D : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_0E : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
INIT_0F : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
InstancePath : STRING := "*";
MsgOn : BOOLEAN := True;
TimingChecksOn : BOOLEAN := True;
Xon : BOOLEAN := True;
thold_ADDR_CLK_negedge_posedge : VitalDelayArrayType(11 downto
0) := (others => 0.01 ns);
thold_ADDR_CLK_posedge_posedge : VitalDelayArrayType(11 downto
0) := (others => 0.01 ns);
thold_DI_CLK_negedge_posedge : VitalDelayArrayType(0 downto 0)
:= (others => 0.01 ns);
thold_DI_CLK_posedge_posedge : VitalDelayArrayType(0 downto 0)
:= (others => 0.01 ns);
thold_EN_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
thold_EN_CLK_posedge_posedge : VitalDelayType := 0.01 ns;
thold_RST_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
thold_RST_CLK_posedge_posedge : VitalDelayType := 0.01 ns;
thold_WE_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
thold_WE_CLK_posedge_posedge : VitalDelayType := 0.01 ns;
tipd_ADDR : VitalDelayArrayType01(11 downto 0) := (others =>
(0.0 ns,0.0 ns));
tipd_CLK : VitalDelayType01 := (0.0 ns,0.0 ns);
tipd_DI : VitalDelayArrayType01(0 downto 0) := (others => (0.0
ns,0.0 ns));
tipd_EN : VitalDelayType01 := (0.0 ns,0.0 ns);
tipd_RST : VitalDelayType01 := (0.0 ns,0.0 ns);
tipd_WE : VitalDelayType01 := (0.0 ns,0.0 ns);
tpd_CLK_DO : VitalDelayArrayType01(0 downto 0) := (others =>
(0.10000000000000001 ns,0.10000000000000001 ns));
tpw_CLK_negedge : VitalDelayType := 0.01 ns;
tpw_CLK_posedge : VitalDelayType := 0.01 ns;
tsetup_ADDR_CLK_negedge_posedge : VitalDelayArrayType(11 downto
0) := (others => 0.01 ns);
tsetup_ADDR_CLK_posedge_posedge : VitalDelayArrayType(11 downto
0) := (others => 0.01 ns);
tsetup_DI_CLK_negedge_posedge : VitalDelayArrayType(0 downto 0)
:= (others => 0.01 ns);
tsetup_DI_CLK_posedge_posedge : VitalDelayArrayType(0 downto 0)
:= (others => 0.01 ns);
tsetup_EN_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
tsetup_EN_CLK_posedge_posedge : VitalDelayType := 0.01 ns;
tsetup_RST_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
tsetup_RST_CLK_posedge_posedge : VitalDelayType := 0.01 ns;
tsetup_WE_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
tsetup_WE_CLK_posedge_posedge : VitalDelayType := 0.01 ns
);
-- synopsys translate_on
port (
ADDR : in STD_LOGIC_VECTOR(11 downto 0);
CLK : in std_ulogic;
DI : in STD_LOGIC_VECTOR(0 downto 0);
EN : in std_ulogic;
RST : in std_ulogic;
WE : in std_ulogic;
DO : out STD_LOGIC_VECTOR(0 downto 0)
);
end component;
---- Constants -----
constant VCC_CONSTANT : STD_LOGIC := '1';
constant GND_CONSTANT : STD_LOGIC := '0';
---- Signal declarations used on the diagram ----
signal GND : STD_LOGIC;
signal VCC : STD_LOGIC;
---- Configuration specifications for declared components
-- synopsys translate_off
for U1 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U10 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U11 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U12 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U2 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U3 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U4 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U5 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U6 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U7 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U8 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U9 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
begin
---- Component instantiations ----
U1 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"f0c33cf0f0f00f0ff0f00f0f0f3cc30ffc03fcc003fc033ffcc03fc0033fc03f",
INIT_01 => X"000000000000000000000000000000006a52a92aaa6aa5a995a5565554954a56",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"ffcccc33f3cccc33cc3333cfcc3333ffcf30f30cf30c00ffff0030cf30cf0cf3",
INIT_05 => X"73733939ccccc7c7e3e333339c9ccecefcc0033ff0030ffc3ff0c00ffcc0033f",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"f030300c000f0fcff3f0f000300c0c0ffff00ff30ff0300ff00c0ff0cff00fff",
INIT_09 => X"f81ffa07fa05fa05a05fa05fe05ff81ff300cff3cff3300ff00ccff3cff300cf",
INIT_0A => X"ff00abd5ff002addbb5400ffabd500ff4df3df3004ff4df3cfb2ff200cfbcfb2",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(0),
EN => VCC,
RST => GND,
WE => GND
);
U10 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"3030cfcfcfcf3030f3f30c0c0c0cf3f33cc33cc30ff00ff0f00ff00f3cc33cc3",
INIT_01 => X"000000000000000000000000000000007ffcf0c0fcf0c000fffcf0c0fcf0c000",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"3cccccc3cfc3c330f330300c3c0c0cc30303ccfc3f33c0c0fcff3303c0cc3f33",
INIT_05 => X"7ffefeeafefaeaa8eaa8a880a8a0800133cc33cc3cc333c03c333cc3cc33fc33",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"ff000000ff0f0f00ff000000ff0f0f00f3cf30f3f3cf00f0f3ff0c3030ff0c30",
INIT_09 => X"91896e76767789e8e8ee159191896e76fc00ffcc0033ff00ffc033fffc00ffc0",
INIT_0A => X"d2d64bd2696b2969696b2d69b42d96b4a55a5aada55a5aa55aa5a55a5aa5a55a",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(5),
EN => VCC,
RST => GND,
WE => GND
);
U11 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"000ccccc000ccccccccfffffcccfffff33ff33ff33ffffff0033003300333333",
INIT_01 => X"000000000000000000000000000000007cc3c33cc30f3cf0f8c3873cc31e3ce0",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"ccc0c0c3c30303333333333c3f3c3cccc00ff00f0ff0033f03fcf00f0ff00ff0",
INIT_05 => X"3cc3c33cc30c3cc33cc3c33cc31c3cc3c0f03f030f03f0fc00f03f0f3f0fc0fc",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"ff0000f0f00f0f00ff0000f0f00f0f00cfcf0030cc0c30333033cfcff3f3cc0c",
INIT_09 => X"a779615a1a8786e1791e1a87a779615acf33c330cc33cc33330c33ccc330f33c",
INIT_0A => X"922664d9d992b66d499b926464d9d9b6999c98c667717119673971998ee6e667",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(3),
EN => VCC,
RST => GND,
WE => GND
);
U12 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"0ff3300f0ff000ff0ff000ffff300cff0300fc3fff0300ff03c0ff3fff00c0ff",
INIT_01 => X"0000000000000000000000000000000073633133cc8cc6cee6c6676698198c98",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"f03c3c0f0fc3c3f0c3f0f03f3c0f0ff0c3f3cfc3cfc33cc33c3cf33cf33cc330",
INIT_05 => X"4fb0f20d3cc3cb34cf30f00f2cd3c33ccff3cccc3ccc3330333cf333cff3cccc",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"0f3030ffff0000ff0cf0f0ffcf0000fff0000ffc0fffc00f000ff000f0000ff0",
INIT_09 => X"a5baa5a25a5f5a5f5a055a05a5faa5bac33c0cc30cc33cccc3300cc30cc33c0c",
INIT_0A => X"999966b3999966bb6632996666b39966699a96a69669699a9624694969929624",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(1),
EN => VCC,
RST => GND,
WE => GND
);
U2 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"ccc00333ccc33333333ccccc33fccccccc33cf33cc333333330c33cc33cc0ccc",
INIT_01 => X"0000000000000000000000000000000040bf02ff33cc3bccc43b44bb23dd33dc",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"000c0c0f0fcfcfff3000000f0c0f0fffcfff303030300ccf0c0cfff3fff33000",
INIT_05 => X"b0ff00f2f3cf30fb30ff00f0f3df30f3c330c33cf33cf00c0ff3cff0c330c33c",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"f0c0c00f0f0f0ff0f000000f0f0f0ff03c3ccc3c33c33c333c333c3cc3c333c3",
INIT_09 => X"39dcc63b63999c669c666399399cc62303c00f03f0fcc0f0fc3ff0fc0f033f0f",
INIT_0A => X"4bb4d2bcb44b2d4b2dc24bd2d2bcb42d177a7ea17ee8e8857ea1e817e885815e",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(2),
EN => VCC,
RST => GND,
WE => GND
);
U3 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"c3c3c3c3c3c3c3c33c3c3c3c3c3c3c3ccccccccc3333333333333333cccccccc",
INIT_01 => X"0000000000000000000000000000000070f30c30f3ff30f0f0f30830f3ef30f0",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"0ff0f00cf30c0cc33cc3c330cf30300f03c333c33c333c3cc3c033c33c333c33",
INIT_05 => X"6aa9a995a9a595569556566a564a6aa93000f0f00f0f000c0fff0f0ff0f0cff3",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"000000ff000f0fff000000ff000f0fff3cc3c30c3cc3f30f0cf03cc3cf303cc3",
INIT_09 => X"c69e869c9c191879616763e6c69e869c03ccfc33ff3300cccc3f330003cccc3f",
INIT_0A => X"b99d22bb44469dd4d446b9dd22bb4462eeefeff7888e8eee88ce8eee00080888",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(4),
EN => VCC,
RST => GND,
WE => GND
);
U4 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"ff00ff00ff00ff00ff00ff00ff00ff00ffff0000ffff0000ffff0000ffff0000",
INIT_01 => X"00000000000000000000000000000000ff00ff00ff00ff00ff00ff00ff00ff00",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"ff0c0c00ffcfcf00ff000000ff0f0f00ffff0000ffff0000ffff0000ffff0000",
INIT_05 => X"ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"ff0c0c00ffcfcf00ff000000ff0f0f00ffff0000ffff0000ffff0000ffff0000",
INIT_09 => X"ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00",
INIT_0A => X"ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(11),
EN => VCC,
RST => GND,
WE => GND
);
U5 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"f00f3fc03fc00ff0f00ffc03fc030ff0f3300ccf0ffff000fff0000f0ccff330",
INIT_01 => X"00000000000000000000000000000000255a5aa5a55a5aa55aa5a55a5aa5a55a",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"30f0f0f30c0c0c3cc3c3c3cf303030f30c0cf0f0cfc30f0f0f0f3c0cf0f0cfc3",
INIT_05 => X"daa5a55a5aa5a55aa55a5aa5a55a5aa40fc30fc3fc3ff03c03f003c03c0f3c0f",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"c33c3c3c3cccccc33cc3c3c3c333333cff3000ff00cfff00ff000cff00fff300",
INIT_09 => X"dad2b4a45b5ad2b2b2b4a525dad2b4a4f00f0ff0f03c0ff0f00fc3f0f00f0ff0",
INIT_0A => X"dfdbb0204d4ff2b2b2b00d4dfbf22404f550500af550500aaff5f550aff5f550",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(6),
EN => VCC,
RST => GND,
WE => GND
);
U6 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"3fcc003f003fcc033fcc03ff03ffcc03000ff330f00ffff0f0000ff0f3300fff",
INIT_01 => X"00000000000000000000000000000000b44f4ff2f22c2ccb2ccbcbb0b00d0dd3",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"fc3c3c3fc0c0c0f0f0f0f0fc030303c0f0f00000f0fc0000ffffc0f0fffff0fc",
INIT_05 => X"b0cb0db0d30d34d334d34f34f24f2cf2ff33ff3333003f03ff03ff3333003300",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"3ffcfcfcf0c0c0c0fcf0f0f0c0000003000fff00f00ffff0f0000ff0ff000fff",
INIT_09 => X"3fdcc403bfdcc0033ffcc4023fdcc4033fcc003f03ffcc033fcc003f03ffcc03",
INIT_0A => X"2ff0f0f0f040f00f0ff0fdf0f0f0f00b344f4ff0f22c2cc33ccbcbb0f00d0dd3",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(8),
EN => VCC,
RST => GND,
WE => GND
);
U7 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"0030ffff0000f3ff0030ffff0000f3ff00ff00ff00f000ff00fff0ff00ff00ff",
INIT_01 => X"0000000000000000000000000000000000ff00ff00ff00ff00ff00ff00ff00ff",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"000c0cff00cfcfff000000ff000f0fff00ffffff000000ff00ffffff000000ff",
INIT_05 => X"00ff00ff20ff00ff00ff00fb00ff00ff00f0f0ff00f0f0ff00f0f0ff00f0f0ff",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"000c0cff00cfcfff000000ff000f0fff00ff00ff00f000ff00fff0ff00ff00ff",
INIT_09 => X"00f330ff00f330ff00f330ff00f330ff0030ffff0000f3ff0030ffff0000f3ff",
INIT_0A => X"00ff000f0fff00ff00ff000f0fff00ff00ff00ff00ff00ff00ff00ff00ff00ff",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(10),
EN => VCC,
RST => GND,
WE => GND
);
U8 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"f0c3f0f0f0f03cf0f0c3f0f0f0f03cf0fff0ffff000f0000ffff0fff0000f000",
INIT_01 => X"00000000000000000000000000000000fbb0b000fff3f330f3303000fff2f220",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"f30c0cf030cfcf00ff0000f3f00f0f30ff0000ff00ffff00ff0000ff00ffff00",
INIT_05 => X"ff30f200dff2fb20fb20b004ffb0f300f00f0ff0f00f0ff0f00f0ff0f00f0ff0",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"f00c0cf300cfcf30f30000ff300f0ff0fff0ffff000f0000ffff0fff0000f000",
INIT_09 => X"f02ccbf0f02ccff0f00ccbf0f02ccbf0f0c3f0f0f0f03cf0f0c3f0f0f0f03cf0",
INIT_0A => X"ff0f0ff0f0bf0f00ff0f02f0f00f0f00fbb0b000fff3f330f3303000fff2f220",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(9),
EN => VCC,
RST => GND,
WE => GND
);
U9 : RAMB4_S1
-- synopsys translate_off
generic map (
INIT_00 => X"c3cc33f333f3cc3cc3cc30333033cc3cf00ffcc0000ff00f0ff00ffffcc00ff0",
INIT_01 => X"0000000000000000000000000000000046636339399c9cc69cc6c6636339399c",
INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 => X"0ccccccfc3c3c3f33030303c0c0c0ccf0f0f00000f03f0f0f0f03f0fffff0f03",
INIT_05 => X"63c639639c39c69cc69c63c639639c39330c330ccf33c330333c330ccf33cf33",
INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 => X"cf0c0c0cf3c3c3cf0c303030cf0f0f0cf00ff0f00f3ff00f0ff0030ff0f00ff0",
INIT_09 => X"e31cc738639ce33cc338c639e31cc738c3cc33c33c03cc3cc3cc3fc33c33cc3c",
INIT_0A => X"df2000ffb24fff00ff000db200fffb04c6636333399c9cccccc6c6633339399c",
INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
)
-- synopsys translate_on
port map(
ADDR => ADDR,
CLK => CLK,
DI(0) => GND,
DO(0) => dout(7),
EN => VCC,
RST => GND,
WE => GND
);
---- Power , ground assignment ----
GND <= GND_CONSTANT;
VCC <= VCC_CONSTANT;
end RAm;
Article: 39732
Hi,
Phil Hays <spampostmaster@attbi.com.com> wrote:
> The third alternative is formal verification. I have no experience in
> such tools, so does anyone have experience, opinions (or both) on the
> question of would this help to produce FPGA hardware that matches the
> original C?
The formal verification tools on market do equivalence checking between
VHDL, Verilog and similar HDL. What you need is a tool for model checking
between C and VHDL. I don't think, you might find such a tool. I remember
that a tool for formal verification of software claims to do so in further
versions, but don't expext too much in the next years.
Another point is, that equivalence checking do well for designs up to 1M
gates. Modelchecking usually needs small designparts of a few thousand
gates.
bye Thomas
--
Thomas Stanka TE/EMD4
Space Communications Systems
Tesat Spacecom GmbH & Co KG
thomas.stanka@tesat.de
Article: 39733Just use foundatation 4.1!Article: 39734
why does the JTAG CABLE not work on Dell systems for programming vertex FPGA's.Article: 39735
shiva kumar wrote: > why does the JTAG CABLE not work on Dell systems for programming > vertex FPGA's. More details needed before the collective might of this NG can help you. How does it "not work" ? What error messages are you getting from JTAGProgrammer or iMPACT ? What Xilinx s/w are you using ? Do the rest of the tools work o.k. ?Article: 39736
Julian Cox <CoxJAisaspamhater@august-systems.co.uk> writes: <snip> > This time I've gone for the xeons A) to avoid P4 (crapomatic) and B) > the cost of RAID has gone up. I'd have gone Dual MP1900+ if I could > have found one. Quantity of RAM is easy to gauge once to get going, > just make sure you choose a PC that can take shedloads if it proves > necessary. > Erm, sorry, but I think the Xeons are P4 core these days as well... certainly they are NetBurst(TM :-) http://www.intel.com/eBusiness/products/workstation/midhigh/ds011403.htm I don't think the old Xeon core could make it to 1.7GHz - I'll be happy to be corrected though as I'm just pondering what to buy for my next workstation... Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 39737
I've generated an altclklock using the Altera megafunction wizard and Quartus 2 1.1 SP2 is happy to synthesise and P&R. However the same file is not at all happy in Leonardo (2001_1d Altera edition). Synthesis should create a black box but then P&R back with Quartus 2 doesn't work. I believe this was working fine last time I tried with a similar P&R, but my Quartus 2 version has incremented (previously used version probably Q2 1.0 SP2 or 1.1 no SP) I suspect that the library altera_mf used to be something else??? Can someone with an earlier version of Q2 try generating a simple PLL (I used a clock 1 @ 133MHz PLL x1 with a 'locked' output but this was an arbitrary choice) and compare the included library to that below. Here's an extract from the generated file: LIBRARY ieee; USE ieee.std_logic_1164.all; LIBRARY altera_mf; USE altera_mf.altera_mf_components.all; ENTITY plltest IS PORT ( inclock : IN STD_LOGIC ; locked : OUT STD_LOGIC ; clock1 : OUT STD_LOGIC ); END plltest; ARCHITECTURE SYN OF plltest IS <snipped> END SYN; --------------------------------------- Not sure that use of altera_mf is the same as before.... Any insights appreciated. PaulArticle: 39738
"shiva kumar" <shivak210m@yahoo.com> wrote in message news:ee74e9d.-1@WebX.sUN8CHnE... > why does the JTAG CABLE not work on Dell systems for programming > vertex FPGA's. I have seen this problem on a few different PCs, and it is usually due to incorrect or missing parallel port driver software. Check out the following records in the Xilinx database: Answer Record 13360, 11502, 9984. MH.Article: 39739
Stromeko@nexgo.de (Achim Gratz) wrote in message news:<73b09d4c.0202080804.4f7a69a0@posting.google.com>... > [...] As an addition to the earlier summary for those interested: As it turned out that you need to have a uniformly distributed stream of integer numbers, I conducted another search in that direction. Generally you'll get lots of hits on (software) implementations for general computers and the tricks required to produce floating point numbers out of integers and vice versa plus appplications to cryptography and/or Monte Carlo simulation. Some of the successful search terms: PRNG QRNG RNG LFSR GFSR Tausworthe (PRBS parallel) A site with lots of useful references: http://www.ciphersbyritter.com In there it is briefly mentioned that you should collect the bits for your output from equally distributed places in the sequence, which seems to relate to Ray Andrakas remark that one could use several LFSR seeded at different places to get a multibit output. I have not found an efficient way to compute the required seed values for really long sequences, however. Notes: I found a hint in an earlier article in this group on how to efficiently describe an "unrolled" LFSR that behaves like it is clocked n times per tick. It involves writing up the original state machine inside a for...loop in VHDL and collecting the outputs and the new shift bits in the appropriate registers. If anybody is interested I can post the code. There is also an easy way to prevent the synthesis from infering SRL16 on Xilinx if you desire: Ray Andraka mentioned that a RESET will do the trick, you can also copy the LFSR state to a variable, change that and assign the changed state back to the LFSR registers. Look Ma, everything done with FF now ... Achim.Article: 39740
Hy!!! I'm developing some design in a Xiling VirtexE 100, until now everything used to work O.K., but since the design is becomming bigger (now i'm using something like 90 % of the slices) I am having some problems with the place & route tool. Things that already worked stop working. With the same synthesis result and diferent PAR strategies sometimes I get it to work. It is very strange that higher effort not always means better results. Sometimes it worked with medium effort PAR and failed by highest effort :-( !?!? Now I know which signal is failing, but I can not constraint it because it is an internal path (not an I/O pin) and I dont know what is the name of this signal after Synthesis so I can not constrain it. Could someone help me? Thanks in advance, Paul.Article: 39741
In article <3C698A22.D81224EE@andraka.com>, Ray Andraka <ray@andraka.com> wrote: > There is a tool in the 4.1 tools called xpower that will take the VCD > file from your simulation and the NCD from the place and route to > provide a more accurate power computation based on your simulation. > However, that xpower works like crap. I made a .vcd file with only 100 clock cycles of a Virtex-E XCV200 design that is only about 1/2 full. The .vcd file was only 8 megabytes and xpower hung reading it in. I let it run overnight and when I came in in the morning the thing had crashed. Not ready for prime time. Nate ---------------------------------------------------- Nate Goldshlag nateg@pobox.com Arlington, MA http://www.pobox.com/~nategArticle: 39742
Nate Goldshlag wrote: > In article <3C698A22.D81224EE@andraka.com>, Ray Andraka <ray@andraka.com> > wrote: > > > There is a tool in the 4.1 tools called xpower that will take the VCD > > file from your simulation and the NCD from the place and route to > > provide a more accurate power computation based on your simulation. > > > > However, that xpower works like crap. I made a .vcd file with only 100 clock > cycles of a Virtex-E XCV200 design that is only about 1/2 full. The .vcd file > was only 8 megabytes and xpower hung reading it in. I let it run overnight > and when I came in in the morning the thing had crashed. You might try it in batch mode. GUI is buggy. -- Phil HaysArticle: 39743
Hi Group, I already had some working knowledge of VHDL and Verilog but I would like to get a book or some to guide me for (1) doing design for complex systems AND (2) picking up techniques to clear the dirty corners of HDL design such as async behaviour, signal crossing clock domains, verification, etc that are slightly or even not mentioned in most HDL intro books. I aware of two books for my next digital logic design reading. I would like to get some review from experienced readers for recommendations: 1. "Real Chip Design and Verification Using Verilog and VHDL" VhdlCohen Publishing, ISBN 0-9705394-2-8 2. "VHDL Coding and Logic Synthesis with Synopsys" by Weng Fook Lee Thanks, -pat.Article: 39744
MH wrote: > "shiva kumar" <shivak210m@yahoo.com> wrote in message news:ee74e9d.-1@WebX.sUN8CHnE... > > why does the JTAG CABLE not work on Dell systems for programming > > vertex FPGA's. > > I have seen this problem on a few different PCs, and it > is usually due to incorrect or missing parallel port > driver software. Check out the following records in > the Xilinx database: Answer Record 13360, 11502, 9984. > > MH. There is another circumstance beyond #13360 that might cause the PP driver to get lost. I usually maintain the current Foundation/ISE version, its predecessor, and the most recent webPACK. If I install a new set of s/w and then uninstall an old one the PP driver gets removed during the uninstall. I've also come across the case of another piece of PC s/w that one of our s/w engineers installed on my machine (He didn't have a Win PC, only a Linux box) that had its own PP driver and installed it in the same place as Xilinx installs theirs! Note:. The solution record #9984 is less helpful than it might be since a condition of the Jungo license is that Xilinx may not distribute the WinDrvr.h header file so users of Xilinx s/w cannot write independent code that accesses the WinDrvr PP driver.Article: 39745
Hi, As I am currently reading through the book: Real Chip Design - by Ben - I would highly recommend it for people with medium skills in any of the HDLs. I will try and post a comprehensive review once I finish reading it. But surely this book does address all the issues that you have asked for, in great detail. Good Luck, Srinivasan "Unit Manager" <antipattern@hotmail.com> wrote in message news:e1f38cc5.0202180806.3891e2fb@posting.google.com... > Hi Group, > > I already had some working knowledge of VHDL and Verilog but I would > like to get a book or some to guide me for (1) doing design for > complex systems AND > (2) picking up techniques to clear the dirty corners of HDL design > such as async behaviour, signal crossing clock domains, verification, > etc that are slightly or even not mentioned in most HDL intro books. > > I aware of two books for my next digital logic design reading. I would > like to get some review from experienced readers for recommendations: > > 1. "Real Chip Design and Verification Using Verilog and VHDL" > VhdlCohen Publishing, ISBN 0-9705394-2-8 > 2. "VHDL Coding and Logic Synthesis with Synopsys" by Weng Fook Lee > > Thanks, > > -pat.Article: 39746
Hi Shiva, I have encountered problems using Dell systems with parallel download cables when used with the Hardware Debugger. I don't know if this applies to the JTAG Programmer software or not. Actually, I don't even think it is specific to Dell machines; there have been a number of threads on comp.arch.fpga on this topic. I teach a class at San Jose State, and the entire lab is filled with Dell machines. It seems (by luck of the draw) that some machines will not configure an FPGA correctly. The symptoms? The Hardware Debugger will attempt to configure, and then indicate it was successful. However, the FPGA appears to be "dead". I traced it down to some glitches on the port signals; what happens is that the FPGA is actually configured, and then "accidentally" cleared at the end of the programming sequence. My workaround was to cut traces on the board so that the FPGA cannot be initialized after the first power-on configuration. Now it always configures the first time, but the downside to the workaround is that if you want to configure again, you must cycle the power to the board. Hope that helps, Eric shiva kumar wrote: > > why does the JTAG CABLE not work on Dell systems for programming > vertex FPGA's.Article: 39747
Hello ! I need to implement signed 16x16 bit multiplier in my graduate project, I'm going to use Spartan-II device. The question is: Are the multipliers generated by Xilinx's Multiplier Generator v4.0 IP well optimized ? Can I gain any better performance/resource utilisation building a multiplier block myself (at reasonable effort) ? P.WegrzynArticle: 39748
<ZhengLin> schrieb im Newsbeitrag news:ee74e92.0@WebX.sUN8CHnE... > Just use foundatation 4.1! NO, just install the JTAG-Programmer from Webpack, it will automaticall install the parallel cable driver. -- MfG FalkArticle: 39749
"Antonio" <dottavio@ised.it> schrieb im Newsbeitrag news:fb35ea96.0202172343.7ae21d4b@posting.google.com... > # : WARNING: */RAMB4_S1 SETUP High VIOLATION ON ADDR(8) WITH RESPECT > TO CLK; > # : Expected := 0.01 ns; Observed := 0 ns; At : 1275 ns > # : Time: 1275 ns, Iteration: 3, Instance: /U1/U2/U2/B13. > # : WARNING: */RAMB4_S1 SETUP Low VIOLATION ON ADDR(7) WITH RESPECT TO > CLK; > # : Expected := 0.01 ns; Observed := 0 ns; At : 1275 ns > # : Time: 1275 ns, Iteration: 3, Instance: /U1/U2/U2/B13. I think this problem has been discussed recently, its a bug in the simulation model of the RAM. > and really many other similar warnings, but let's try to understand > what the error say, > the problem is that the clock and the address change on the same time > while from data_sheets > seems that the address must arrive a little bit before 0.01ns. Yes, a "little" bit more, so 2ns or so. ;-) > > The only rimedy I know is to change the operating edge of the ram so > now the address change on > negative edge of the clock and the ram work on positive edge. Now the > simulation it's ok but > the speed on FPGA is reduced to 45MHz. This is clear, since the address changes on the negative edge and has so only 1/2 clock cycle to propaget to the RAM. Switch back to te positive edge and ignore the warning of the simulator. If you have a clean synchronous design, just look at the timing analyzer, it will tell you how fast you can go. -- MfG Falk
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