Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I 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
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
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
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
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 VelocityArticle: 106030
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
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. JohnArticle: 106032
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
>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. MartinArticle: 106034
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 PeteSArticle: 106035
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.nlArticle: 106036
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.deArticle: 106037
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
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: 106039Ayon 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
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
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 JaksonArticle: 106042
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: 106043Has 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
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
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
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 bijoyArticle: 106047
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
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.deArticle: 106049
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:
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