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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 106025

Article: 106025
Subject: Re: Cyclone I & II memory fmax
From: "homoalteraiensis" <fpgaengineerfrankfurt@arcor.de>
Date: 5 Aug 2006 14:18:09 -0700
Links: << >>  << T >>  << A >>
I still discover a difference between the fmax for Cyclone I and
Cyclone II.

Is this caused by the DP-RAM bug with Cyclone II devices -
let's say with the additional hardware produced by the work around?


Article: 106026
Subject: Re: large data access to SDRAM at fixed frequency
From: "homoalteraiensis" <fpgaengineerfrankfurt@arcor.de>
Date: 5 Aug 2006 14:30:24 -0700
Links: << >>  << T >>  << A >>

Im am not sure if it might help you, but sometimes one might have
success with partly blocked writing processes if you run them on higher
speeds than the acquisition.
Could you try to maintain a 33MHz speed to access the RAM?

Data could be fetched from a ring buffer fed at 30Meg from the ADC
interface.


Article: 106027
Subject: Re: ASIC Design Engineer Job in SHENZHEN China
From: "homoalteraiensis" <fpgaengineerfrankfurt@arcor.de>
Date: 5 Aug 2006 14:48:25 -0700
Links: << >>  << T >>  << A >>
Without wanting to start a discussion about jobs, payment and design
skills, I cannot hesitate to comment on this:

To me, the sheet of required skills seems to be right big, and I am
afraid, I would fail in beeing selected. So this should be a job for a
guy having at least 10 years of design experience (analog, digital,
deep product knowledge, team leader ....) so I expected a high
compensation for this. But what I found is $5.000 per month (???) .

Is this a typical compensation for such a job? In Europe, this is less
than =8050.000 per year and doesn't even meet the income of small
SIEMENS engineer with 2 years experience. (A friend of mine recently
started with 48k, coming from the University directly).

Anybody likes to work in Germany?


Article: 106028
Subject: Re: verilog versus vhdl
From: David R Brooks <davebXXX@iinet.net.au>
Date: Sat, 05 Aug 2006 14:56:41 -0800
Links: << >>  << T >>  << A >>
Markus Zingg wrote:
> Hi Group
> 
> I have to implement a design which requires an FPGA, but to do so
> among other things I obviousely first have to learn one of the two
> mentioned languages. I got the impression that europe seems to be more
> vhdl centric whereas verilog seems to be more popular in the US but
> this argument alone is for reasons beond the scope of this question
> not so important to me. I have a strong background in C programming
> (should that matter anyhow) and in general experience with embedded
> systems, but FPGAs are new to me. I'm otherwise completely open and
> alas wonder what you guys suggest I should choose. I'm mostly
> interested in replies from people which know both languages cause
> otherwise I fear that this thread ends up in some sort of religious
> war...
> 
It certainly is a religious war :-)
FWIW, VHDL derives more from Ada, while Verilog derives from C.
This means that VHDL is strongly typed, while (classic) Verilog is not. 
That may be a plus or a minus, according to your viewpoint.

Article: 106029
Subject: Re: MIG 1.6 DDR2 testing problems (FIFO16 related?)
From: Joseph Samson <user@example.net>
Date: Sat, 05 Aug 2006 23:50:27 GMT
Links: << >>  << T >>  << A >>
GaLaKtIkUs™ wrote:

> Did you hard coded the number of needed clock cycles or the delay in
> the IDELAY??
> Thanks for help!

The number of clock cycles needed, not the IODelay.


---
Joe Samson
Pixel Velocity


Article: 106030
Subject: Re: verilog versus vhdl
From: Erik de Castro Lopo <nospam@mega-nerd.com>
Date: Sun, 06 Aug 2006 03:07:37 GMT
Links: << >>  << T >>  << A >>
David R Brooks wrote:
> 
> It certainly is a religious war :-)

Yes.

> FWIW, VHDL derives more from Ada, while Verilog derives from C.

Yes.

> This means that VHDL is strongly typed, while (classic) Verilog is not.

Funnily enough, I did FPGA design using scehmatic entry during 
the  1990s with a little bit of VHDL (which I hated). I then 
became a software engineer for a number of years. Currently my 
favourite language is Ocaml which is at least as strongly typed
as ADA.

However, when I came back to FPGA design recently I gave Verilog 
a look and found that I much prefered it over VHDL. I prefer 
Verilog mostly because for me, I find it easier to map my ideas 
to the language. However, for FPGA design, I do think in logic 
rather than language.

Given the above, I'm sure it would be possible to find someone 
who says something similar to the above but swaps VHDL for 
Verilog.


Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
Open Source and Free Software means that you never sacrifice quality
of the code for meeting deadlines set up by people not participating
directly in the software development process.

Article: 106031
Subject: Re: verilog versus vhdl
From: fpga_toys@yahoo.com
Date: 6 Aug 2006 00:10:32 -0700
Links: << >>  << T >>  << A >>

Erik de Castro Lopo wrote:
> Given the above, I'm sure it would be possible to find someone
> who says something similar to the above but swaps VHDL for
> Verilog.

Or who can make a strong argument for C synthesis in certain markets.
System C, Streams-C (Impluse), Handel-C (Celoxica), or even FpgaC as it
matures this next year. As I work on new algorithms and technology
mapping for FpgaC I find myself amazed some days that the demo code is
natural coding in C, and better than difficult hand coding in
VHDL/Verilog in suprising cases. The original synthesis I got from TMCC
is both amazing sometimes, and sucks horribly others, but that
horribleness is going away soon with Beta-3 and Beta-4 releases the
second half of this year.

Both Handel-C and Streams C have their shining moments too, with their
commercial releases maturing into world class sythesis tools as well.
I've seen some pretty awesome projects implemented using Celoxica
tools.

John


Article: 106032
Subject: Re: 100m JTAG cable
From: "Simon Peacock" <simon-quicksilver_net_nz>
Date: Sun, 6 Aug 2006 20:47:18 +1200
Links: << >>  << T >>  << A >>
Take a look at an Eden PC from VIA.  If it meets your requirements for a PC
it can run Linux or Windose and doesn't need a SMPSU.  It can also have a
cardbus main memory instead of a HDD.  They have all the features of a full
PC, cost about NZ$200-300,  They are also fanless so place in a large
concrete/lead/steel box and go for it.

Simon

<jetmarc@hotmail.com> wrote in message
news:1154687760.281624.70350@i42g2000cwa.googlegroups.com...
> >  The board will be used to test radiation tolerance techniques, but
> > background radiation is too high to put a PC nearby for control. (and
> > want to use it afterwards:)
>
> If everything else fails, you might dedicate an old (disposable) PC to
> this job.  Put it right next to the FPGA, and remote-control it over
> ethernet with Remote Desktop (comes with WinXP).
>
> Marc
>



Article: 106033
Subject: Re: Cyclone I & II memory fmax
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Sun, 6 Aug 2006 11:19:42 +0200
Links: << >>  << T >>  << A >>
>I still discover a difference between the fmax for Cyclone I and
> Cyclone II.
>
> Is this caused by the DP-RAM bug with Cyclone II devices -
> let's say with the additional hardware produced by the work around?
>
AFAIK the example I'm using (same data width on both ports)
does not need the additional hardware. With different port
widths, which I used first, I got the additional MUX inserted
by Quartus. However, in my application I can tolerate some
latency, so I will MUX the data (and demux) it in an extra
pipeline stage.

Martin 



Article: 106034
Subject: Re: verilog versus vhdl
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 6 Aug 2006 02:37:54 -0700
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> Erik de Castro Lopo wrote:
> > Given the above, I'm sure it would be possible to find someone
> > who says something similar to the above but swaps VHDL for
> > Verilog.
>
> Or who can make a strong argument for C synthesis in certain markets.
> System C, Streams-C (Impluse), Handel-C (Celoxica), or even FpgaC as it
> matures this next year. As I work on new algorithms and technology
> mapping for FpgaC I find myself amazed some days that the demo code is
> natural coding in C, and better than difficult hand coding in
> VHDL/Verilog in suprising cases. The original synthesis I got from TMCC
> is both amazing sometimes, and sucks horribly others, but that
> horribleness is going away soon with Beta-3 and Beta-4 releases the
> second half of this year.
>
> Both Handel-C and Streams C have their shining moments too, with their
> commercial releases maturing into world class sythesis tools as well.
> I've seen some pretty awesome projects implemented using Celoxica
> tools.
>
> John

I personally feel more comfortable with Verilog, but there are times
VHDL does a better job, and I use both (sometimes within one design).
I'm a hardware designer with a strong background in C (and a fair
amount of C++), so verilog feels more natural to me.

FWIW, my experience is that those who trained in hardware _tend_ to
prefer verilog, those who started more with strongly typed code _tend_
to prefer VHDL.

Cheers

PeteS


Article: 106035
Subject: Re: verilog versus vhdl
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 06 Aug 2006 09:45:04 GMT
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:

>
>Erik de Castro Lopo wrote:
>> Given the above, I'm sure it would be possible to find someone
>> who says something similar to the above but swaps VHDL for
>> Verilog.
>
>Or who can make a strong argument for C synthesis in certain markets.
>System C, Streams-C (Impluse), Handel-C (Celoxica), or even FpgaC as it
>matures this next year. As I work on new algorithms and technology
>mapping for FpgaC I find myself amazed some days that the demo code is
>natural coding in C, and better than difficult hand coding in
>VHDL/Verilog in suprising cases. The original synthesis I got from TMCC
>is both amazing sometimes, and sucks horribly others, but that
>horribleness is going away soon with Beta-3 and Beta-4 releases the
>second half of this year.

Sounds interesting. Got any websites?
BTW, when I studied electronics (about 10 years ago), I had to use a C
derivative based on the Gnu C compiler to create test patterns for a
piece of IC design.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 106036
Subject: Xilinx Impact USB speed problem
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 6 Aug 2006 12:18:28 +0200
Links: << >>  << T >>  << A >>
Starting with ISE Webpack 8.2, I have to manually set the speed of the USB
port to 3 MHz every time I start Impact, because with 6 MHz the write
process is ignored most of the time and the old configuration is still
active. How can I preset 3 MHz? Looks like it is not stored in the Impact
project file.

Or any other ideas why 6 MHz doesn't work on my computer?

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 106037
Subject: Re: 100m JTAG cable
From: Austin Lesea <austin@xilinx.com>
Date: Sun, 06 Aug 2006 08:23:53 -0700
Links: << >>  << T >>  << A >>
I appreciate the post,

And I am sure others do as well.

But, cosmic ray induced neutrons and protons go through up to 30 meters 
of concrete.  Alphas are stopped by a piece of paper.

So, if you are near a particle beam, there are recoils, strays, etc. at 
60 to 800 Mev, and shielding is not very effective.  Or even when you 
are anywhere here on earth (except for a cave).

That is why our reliability engineers who work for the FPGA Lab wear a 
film badge, and have radiation effects training.

Now, as it turns out, their total dose is pretty small, and is less than 
the dose they get from the airplane flights to get there, but when they 
set off the contamination alarms (it happens), that doesn't help much!

Turns out Los Alamos has some pretty strong low pressure events, and the 
radon from the surrounding ground can come right out, bond to dust, and 
if it gets on your clothes:  ding ding ding (red lights), and you find 
yourself in the back of the little white van off to the contamination 
center where there is a little wait to discover that pesky patch of dust 
where you bent down to straighten the cable...

Austin

Simon Peacock wrote:

> Take a look at an Eden PC from VIA.  If it meets your requirements for a PC
> it can run Linux or Windose and doesn't need a SMPSU.  It can also have a
> cardbus main memory instead of a HDD.  They have all the features of a full
> PC, cost about NZ$200-300,  They are also fanless so place in a large
> concrete/lead/steel box and go for it.
> 
> Simon
> 
> <jetmarc@hotmail.com> wrote in message
> news:1154687760.281624.70350@i42g2000cwa.googlegroups.com...
> 
>>> The board will be used to test radiation tolerance techniques, but
>>>background radiation is too high to put a PC nearby for control. (and
>>>want to use it afterwards:)
>>
>>If everything else fails, you might dedicate an old (disposable) PC to
>>this job.  Put it right next to the FPGA, and remote-control it over
>>ethernet with Remote Desktop (comes with WinXP).
>>
>>Marc
>>
> 
> 
> 

Article: 106038
Subject: clock problems with Spartan 3E starter kit
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 6 Aug 2006 19:49:06 +0200
Links: << >>  << T >>  << A >>
I'm trying to use the ethernet controller on my starter kit. This chip
generates a 25 MHz clock and with every rising edge I have to sample 4 bits
of data. First I've tried to synchronize to rising_edge of E_RX_CLK and
wrote this for testing:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity network_test is
  port(
    CLK_50MHZ: in std_logic;
    E_RXD: in unsigned(4 downto 0);
    E_RX_CLK: in std_logic;
    E_RX_DV: in std_logic;
    E_TXD: buffer std_logic_vector(3 downto 0);
    E_TX_EN: out std_logic;
    E_MDC: out std_logic;
    E_MDIO: out std_logic;
    led: out unsigned(7 downto 0));
end entity network_test;

architecture rtl of network_test is
  signal main_test: std_logic := '0';
  signal rx_test: std_logic := '0';
  signal main_counter: natural range 0 to 12500000 := 0;
  signal rx_counter: natural range 0 to 12500000 := 0;

begin

  main_process: process(CLK_50MHZ)
  begin
    if rising_edge(CLK_50MHZ) then
      if main_counter = 0 then
        main_counter <= 12500000;
        main_test <= not main_test;
      else
        main_counter <= main_counter - 1;
      end if;
    end if;
  end process;

  rx_process: process(E_RX_CLK)
  begin
    if rising_edge(E_RX_CLK) then
      if rx_counter = 0 then
        rx_counter <= 12500000;
        rx_test <= not rx_test;
      else
        rx_counter <= rx_counter - 1;
      end if;
    end if;
  end process;
  
  led(0) <= main_test;
  led(1) <= rx_test;
  led(2) <= E_RX_DV;

  led(7 downto 3) <= E_RXD(4 downto 0);

  E_MDC <= '0';
  E_MDIO <= '0';
  E_TXD <= (others => '0');
  E_TX_EN <= '0';

end architecture rtl;


But it doesn't work: LED 1 is off all the time, but I expected it to blink
with 1 Hz. LED 0 is blinking with 2 Hz.

But looks like it reads some data, because I can see activity on the LEDs 3
to 7 on network activiy. The scope shows the 25 MHz clock signal on the
network chip output, but the Spartan 3E chip is ignoring it. How can I
sample this data with rising edge of E_RX_CLK and is block RAM fast enough
for saving it?

This is the UCF file:


NET "led<0>"         LOC =  "F12";
NET "led<1>"         LOC =  "E12";
NET "led<2>"         LOC =  "E11";
NET "led<3>"         LOC =  "F11";
NET "led<4>"         LOC =  "C11";
NET "led<5>"         LOC =  "D11";
NET "led<6>"         LOC =  "E9";
NET "led<7>"         LOC =  "F9";
NET "CLK_50MHZ"      LOC =  "C9";
NET "CLK_50MHZ" PERIOD = 20 ns HIGH 40 %;
NET "E_MDC"          LOC =  "P9";
NET "E_MDIO"         LOC =  "U5";
NET "E_TX_EN"        LOC =  "P15";
NET "E_TXD<0>"       LOC =  "R11";
NET "E_TXD<1>"       LOC =  "T15";
NET "E_TXD<2>"       LOC =  "R5";
NET "E_TXD<3>"       LOC =  "T5";
NET "E_RX_DV"        LOC =  "V2";
NET "E_RXD<0>"       LOC =  "V8";
NET "E_RXD<1>"       LOC =  "T11";
NET "E_RXD<2>"       LOC =  "U11";
NET "E_RXD<3>"       LOC =  "V14";
NET "E_RXD<4>"       LOC =  "U14";
NET "E_RX_CLK"       LOC =  "V3";
NET "E_RX_CLK" PERIOD = 40 ns HIGH 40 %;

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 106039
Subject: Re: DDR Controller
From: "yy" <yy7d6@yahoo.com.ph>
Date: 6 Aug 2006 13:25:23 -0700
Links: << >>  << T >>  << A >>
Ayon kay Nicolas Matringe:
> yy a =E9crit :
> [...]
> > With the PCI Master core connected to a DMA Engine and FIFO buffer that
> > is connected to the 'DDR SDRAM Controller Interface' that is connected
> > to the DDR Module itself, and if possible be connected to other DDR
> > Controller Interface, can that be possible? such that when I access
> > BAR1, for example i'm accessing DDR1 Interface, BAR2 for DDR2 Interface
> > etc., along with this a Custom logic1 that use DDR1as its data must be
> > able to access the same 'DDR Controller Interface1' , Custom Logic2
> > that use DDR2 as its data must be able to access the same DDR
> > Controller Interface2, etc.
>
>
> Hi
> There's really *nothing* fancy here.
> Imagine a system with a microprocessor (with integrated cache), DDR and
> a PCI bus...
>
> Nicolas

Does it mean that you can interface both a DMA Engine along with
another logic(say some other FIFO, etc.) that use the memory on a same
DDR SDRAM Interface?... kinda think of that...


Article: 106040
Subject: Re: verilog versus vhdl
From: Phil Hays <spampostmaster@comcast.net>
Date: Sun, 06 Aug 2006 13:35:38 -0700
Links: << >>  << T >>  << A >>
Markus Zingg wrote:

> I have to implement a design which requires an FPGA, but to do so among
> other things I obviousely first have to learn one of the two mentioned
> languages. I got the impression that europe seems to be more vhdl
> centric whereas verilog seems to be more popular in the US but this
> argument alone is for reasons beond the scope of this question not so
> important to me. I have a strong background in C programming (should
> that matter anyhow) and in general experience with embedded systems, but
> FPGAs are new to me. I'm otherwise completely open and alas wonder what
> you guys suggest I should choose. I'm mostly interested in replies from
> people which know both languages cause otherwise I fear that this thread
> ends up in some sort of religious war...

There are industries and locations where your choice should be made by
looking at what others do.  Regardless which language is "best", picking
the language that few use locally or in the industry isn't wise.  This is
true both as an engineer, and as an employer.  Start by finding what the
local standard is, pick that, and move on. While nationwide there are more
openings for FPGA VHDL designers (Today on Monster.com, "verilog and fpga"
149 openings, "vhdl and fpga" 228 openings), there are clearly some
industries, types of applications, some companies and some geographic
areas that are very much the reverse. Try the same two searches for your
zip code, and/or for your industry, your application, your company.


-- 
Phil Hays (Xilinx, but writing for myself)

Article: 106041
Subject: Re: verilog versus vhdl
From: "JJ" <johnjakson@gmail.com>
Date: 6 Aug 2006 14:57:10 -0700
Links: << >>  << T >>  << A >>

Markus Zingg wrote:
> Hi Group
>
> I have to implement a design which requires an FPGA, but to do so
> among other things I obviousely first have to learn one of the two
> mentioned languages. I got the impression that europe seems to be more
> vhdl centric whereas verilog seems to be more popular in the US but
> this argument alone is for reasons beond the scope of this question
> not so important to me. I have a strong background in C programming
> (should that matter anyhow) and in general experience with embedded
> systems, but FPGAs are new to me. I'm otherwise completely open and
> alas wonder what you guys suggest I should choose. I'm mostly
> interested in replies from people which know both languages cause
> otherwise I fear that this thread ends up in some sort of religious
> war...
>
> TIA
>
> Markus

google for verilog vhdl language wars, and google back in this group
for lots of previous points

Both languages have been under the auspices of one organisation for
some time now.

http://www.accellera.org/home

Verilog was in the past and still is much better at very low level
things typically done in ASICs such as working with ASIC std cell
libraries where VHDL models came much later. The EDA industry used to
favor it but after synthesis came along, translating both into a common
neutral format makes the point moot, you end up with the same thing.
ModelSim and other simulators have had a common internal format for
along time now.

VHDL was in the past and still is better at systems sorts of things and
appears to have more presence in FPGAs, military, edu, europe, telcos?
etc. I think though that ASIC design atleast in the US and Asia is
still mostly Verilog but there are exceptions to all the above.

Both languages overlap a lot, in pretty much the areas where most users
now work. verilog has recently been borrowing ideas from VHDL and is
generally a terser language.

You can easily compare their styles by checking out the big blue book
by Douglas J Smith in HDL Chip Design. The newer editions I believe
cover FPGAs too. Hives example suorces in both, along with nice
schematics and docs.

Myself I vote for the one that begins with V.

Now if the C language would pick up some major extensions the likes of
which we see in HDLs such as open ended bit sizes and the same notion
of concurrency and nested modules I could probably do most everthing in
a HDL C combined with regular C. If the compiler would spit out HDL for
regular synthesis and allow HDL code to be simulated at C speeds, that
would be neat.

John Jakson


Article: 106042
Subject: Counter status flags don't stay asserted not sure why?
From: "pinod01@sympatico.ca" <pinod01@sympatico.ca>
Date: 6 Aug 2006 15:43:05 -0700
Links: << >>  << T >>  << A >>
To all,

    I have a counter that uses a control input that toggles which
signal I am incrementing.  Both count values are restricted to a range
and so they always stay in this range and wrap around when they go to
the end of the range.  I have some status flags called "full_status"
and "empty_status" to which when the two addresses are equal - a
situation when one of the pointers catches up to the other - the flags
are asserted.  This assertion is to stay active until the control
signal "get_store_ctl" toggles to allow the other pointer to increment.
  Unfortunately the status flags given one state of the "get_store_ctl"
is supposed to stay asserted when "get_addr = store_addr" until as I
mentioned the "get_store_ctl" changes and the pointers themselves are
not supposed to increment at all as I try to freeze this.  This is not
what happens, as the pointer itself keeps incrementing.

The section that is not functioning according to my description is the
section in the VHDL code that has the IF statement that compares
"updated_addr = comp_addr".   Can someone correct the piece of VHDL
code below?   Again I'm expecting that once the flags are asserted
according then the output address is always supposed to stay constant
and not increment.  This is what I would like to happen but for some
reason it's not working this way.


LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_unsigned.ALL;


ENTITY free_memory_addr_counter IS
   GENERIC (NUM_OF_BITS : POSITIVE :=32);
    PORT(
         CLK		:IN STD_LOGIC;
         RST_N	:IN STD_LOGIC;
         PTR_EN	:IN STD_LOGIC;
         GET_STORE_CTL	:IN STD_LOGIC;
         EMPTY_FLAG	    :OUT STD_LOGIC;
         FULL_FLAG	    :OUT STD_LOGIC;
         GET_ADDR_PTR  :OUT  STD_LOGIC_VECTOR (NUM_OF_BITS-1 DOWNTO 0);
         STORE_ADDR_PTR  :OUT  STD_LOGIC_VECTOR (NUM_OF_BITS-1 DOWNTO
0);
         OUT_ADDR	:OUT  STD_LOGIC_VECTOR (NUM_OF_BITS-1 DOWNTO 0)
	);
END ENTITY free_memory_addr_counter;

ARCHITECTURE main_cntr_rtl OF free_memory_addr_counter IS

-- Define parameters
    signal full_status 		:std_logic;
    signal empty_status 	:std_logic;
    signal get_addr  		:std_logic_vector(NUM_OF_BITS-1 DOWNTO 0);
    signal store_addr  		:std_logic_vector (NUM_OF_BITS-1 DOWNTO 0);
    signal updated_addr	:std_logic_vector (NUM_OF_BITS-1 DOWNTO 0);
    signal comp_addr		:std_logic_vector (NUM_OF_BITS-1 DOWNTO 0);

    constant START_MEM_ADDR  :std_logic_vector(NUM_OF_BITS-1 DOWNTO 0)
:= x"01000000";
    constant END_MEM_ADDR	:std_logic_vector(NUM_OF_BITS-1 DOWNTO 0) :=
x"01000003"; --:= x"0100FFFF";

BEGIN

    PROCESS (CLK, RST_N)
    BEGIN
         IF (RST_N = '0') THEN
	get_addr <= START_MEM_ADDR;
	store_addr <= START_MEM_ADDR;
	updated_addr <= (others => '0');
	comp_addr <= (others => '0');
	full_status <= '0';
	empty_status <= '1';
	EMPTY_FLAG <= '1';
	FULL_FLAG <= '0';
	OUT_ADDR <= (others => 'Z');
	GET_ADDR_PTR <= (others => 'Z');
	STORE_ADDR_PTR <= (others => 'Z');

         ELSIF (CLK'EVENT AND CLK = '1') THEN

	IF PTR_EN = '1' THEN

	    IF (GET_STORE_CTL = '1') THEN      -- retrieve an address

	         IF (full_status = '0') THEN
		IF (get_addr /= END_MEM_ADDR) THEN
		     get_addr <= get_addr + 1;
		 ELSE
		     get_addr <= START_MEM_ADDR;
		END IF;
	         ELSE
		get_addr <= get_addr;
	         END IF;
	         store_addr <= store_addr;
	         updated_addr <= get_addr + 1;
                         comp_addr <= store_addr;

	  ELSE	-- return an address to memory

	        IF (empty_status = '1') THEN
		IF (store_addr /= END_MEM_ADDR) THEN
		     store_addr <= store_addr + 1;
		ELSE
		     store_addr <= START_MEM_ADDR;
		END IF;
	        ELSE
		store_addr <= store_addr;
	        END IF;
	        get_addr <= get_addr;
	        updated_addr <= store_addr + 1;
	        comp_addr <= get_addr;
	END IF;

	-- after incrementing check to make sure you did not catch-up
	-- to the other address counter.  If you did then this means
	-- you do not have any more address spaces from SRAM to retrieve
	IF updated_addr = comp_addr THEN
	     full_status <= '1';
	     empty_status <= '0';
	ELSE
	     full_status <= '0';
	     empty_status <= '1';
	END IF;

             ELSE

	get_addr <= get_addr;
	store_addr <= store_addr;
	full_status <= full_status;
                empty_status <= empty_status;
	updated_addr <= updated_addr;
	comp_addr <= comp_addr;

              END IF;

              EMPTY_FLAG <= empty_status;
              FULL_FLAG <= full_status;
              OUT_ADDR <= not get_addr;
              GET_ADDR_PTR <= get_addr;
              STORE_ADDR_PTR <= store_addr;

          END IF;

    END PROCESS;
END ARCHITECTURE main_cntr_rtl;


Article: 106043
Subject: Changing SerDes speed on the V4FX RocketIO
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Sun, 06 Aug 2006 21:19:54 -0400
Links: << >>  << T >>  << A >>
Has anyone been able to dynamically change the SerDes speed on the V4FX
RocketIO. I've been able to get the RocketIO to operate correctly at both
SDR rates (2.5GHz) and DDR (5GHz) rates using static parameters but when I
try to change the speed dynamically the RocketIO enter a state where they
never lock up at any speed. The only way to get them to operate again is
to reload the bit stream. 

In simulation everything works. I diffed the wrappers generated by Coregen
1.1 for the SDR and DDR rates to determine which parameters to change. I
used a simulator to determine the values for each of the relevant
parameter registers in the MGTAs and MGTBs. Writing the registers in
simulation works fine but in real hardware it doesn't work at all.

Has anyone succeeded in getting this to work? Are there any steps that I'm
missing?



Article: 106044
Subject: How do I treat "default" case which is useless?
From: "Mr. Ken" <Mr. Ken@asdf>
Date: Mon, 7 Aug 2006 10:52:52 +0800
Links: << >>  << T >>  << A >>
I need to use only 5 out of the 8 cases, but for completeness's sake,
a default case is needed in order to avoid unwanted latches. This default
case isn't covered by simulation. As a result, it will bring the coverage
down
from 100% to 99%. It's kinda annoying to explain this 1% to customer.

How do I treat this situation?




Article: 106045
Subject: Re: How do I treat "default" case which is useless?
From: John_H <johnhandwork@mail.com>
Date: Mon, 07 Aug 2006 03:50:49 GMT
Links: << >>  << T >>  << A >>
Mr. Ken wrote:
> I need to use only 5 out of the 8 cases, but for completeness's sake,
> a default case is needed in order to avoid unwanted latches. This default
> case isn't covered by simulation. As a result, it will bring the coverage
> down
> from 100% to 99%. It's kinda annoying to explain this 1% to customer.
> 
> How do I treat this situation?

Could you leave the default case blank (but still include the default) 
and get better coverage numbers?  If there's a statement saying "clear 
the register" that will never be executed, it's still a statement that's 
not covered.  If it's blank, will the simulation coverage still have a 
problem that the emty branch was never entered?

Article: 106046
Subject: FPGA : PCI-Xilinx Core, PC not booting
From: bijoy <pbijoy@rediffmail.com>
Date: Sun, 6 Aug 2006 20:51:10 -0700
Links: << >>  << T >>  << A >>
Hello all,

We have made a PCI board using Xilinx PCI core. with master and target capabilities. It works well with intel PCs, but with AMD PCs if i plug the card the PC will not boot.

Does any one had similar expereince ? Any pointers for the cause will be helpful for me

Thank you bijoy

Article: 106047
Subject: Re: 100m JTAG cable
From: "Simon Peacock" <simon-quicksilver_net_nz>
Date: Mon, 7 Aug 2006 18:22:23 +1200
Links: << >>  << T >>  << A >>
but, off course, at $200 you can afford to have a few sitting on the shelf
just in case an electron, photon, neutron, quark, duck etc  decides to go
through a sensitive part of the chip.

Simon


"Austin Lesea" <austin@xilinx.com> wrote in message
news:44D60989.20407@xilinx.com...
> I appreciate the post,
>
> And I am sure others do as well.
>
> But, cosmic ray induced neutrons and protons go through up to 30 meters
> of concrete.  Alphas are stopped by a piece of paper.
>
> So, if you are near a particle beam, there are recoils, strays, etc. at
> 60 to 800 Mev, and shielding is not very effective.  Or even when you
> are anywhere here on earth (except for a cave).
>
> That is why our reliability engineers who work for the FPGA Lab wear a
> film badge, and have radiation effects training.
>
> Now, as it turns out, their total dose is pretty small, and is less than
> the dose they get from the airplane flights to get there, but when they
> set off the contamination alarms (it happens), that doesn't help much!
>
> Turns out Los Alamos has some pretty strong low pressure events, and the
> radon from the surrounding ground can come right out, bond to dust, and
> if it gets on your clothes:  ding ding ding (red lights), and you find
> yourself in the back of the little white van off to the contamination
> center where there is a little wait to discover that pesky patch of dust
> where you bent down to straighten the cable...
>
> Austin
>
> Simon Peacock wrote:
>
> > Take a look at an Eden PC from VIA.  If it meets your requirements for a
PC
> > it can run Linux or Windose and doesn't need a SMPSU.  It can also have
a
> > cardbus main memory instead of a HDD.  They have all the features of a
full
> > PC, cost about NZ$200-300,  They are also fanless so place in a large
> > concrete/lead/steel box and go for it.
> >
> > Simon
> >
> > <jetmarc@hotmail.com> wrote in message
> > news:1154687760.281624.70350@i42g2000cwa.googlegroups.com...
> >
> >>> The board will be used to test radiation tolerance techniques, but
> >>>background radiation is too high to put a PC nearby for control. (and
> >>>want to use it afterwards:)
> >>
> >>If everything else fails, you might dedicate an old (disposable) PC to
> >>this job.  Put it right next to the FPGA, and remote-control it over
> >>ethernet with Remote Desktop (comes with WinXP).
> >>
> >>Marc
> >>
> >
> >
> >



Article: 106048
Subject: Re: Counter status flags don't stay asserted not sure why?
From: Frank Buss <fb@frank-buss.de>
Date: Mon, 7 Aug 2006 08:34:04 +0200
Links: << >>  << T >>  << A >>
pinod01@sympatico.ca wrote:

> The section that is not functioning according to my description is the
> section in the VHDL code that has the IF statement that compares
> "updated_addr = comp_addr".   Can someone correct the piece of VHDL
> code below?

I didn't analyze your code in detail, but if you change a signal in a
process, it will be not changed until the end of the process. Use
variables, if you need some sequential order.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 106049
Subject: Re: MIG 1.6 DDR2 testing problems (FIFO16 related?)
From: heinerlitz@gmx.de
Date: 7 Aug 2006 00:06:27 -0700
Links: << >>  << T >>  << A >>
As I wrote above:

I observed  clk_count_rise and clk_count_fall using chipscope and found
out that they never change which means they are defacto hardcoded. The
delay is hence always the same even without hardcoding the value.
However faillures are still there.

heiner


Joseph Samson schrieb:

> GaLaKtIkUs=99 wrote:
>
> > Did you hard coded the number of needed clock cycles or the delay in
> > the IDELAY??
> > Thanks for help!
>
> The number of clock cycles needed, not the IODelay.
>=20
>=20
> ---
> Joe Samson
> Pixel Velocity




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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search