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 79025

Article: 79025
Subject: Re: Altera's Megafunction altaccumulator
From: "Jezwold" <edad3000@yahoo.co.uk>
Date: 11 Feb 2005 06:47:17 -0800
Links: << >>  << T >>  << A >>
It maybe due to the input types used,unsigned types wider than 32 bits
cannot be used without overflow errors occuring in conversion
functions.I am not sure that is the reason but its worth checking.


Article: 79026
Subject: ISE and IEEE.Fixed_pkg (fixed point math for synth?)
From: ptkwt@aracnet.com (Phil Tomson)
Date: 11 Feb 2005 15:04:58 GMT
Links: << >>  << T >>  << A >>


I'm trying to use the proposed IEEE.fixed_pkg (fixed-point math package) 
available here:

http://www.eda.org/vhdl-200x/vhdl-200x-ft/packages/files.html

The simulator doesn't complain (GHDL in this case), but ISE doesn't seem 
to like the negative values in ranges, like:

  variable exp_value_fp : ufixed( 0 downto -17);

I get this message:

ERROR:Xst:1548 - c:/phil/vhdl/svm/../csvm.vhd line 60: Negative range in 
type of signal <exp_value_fp> is not supported.

1) does fixed_pkg work with other synthesis tools?
2) Suggestions for other alternatives to fixed_pkg that might work with 
ISE?
   

Phil

Article: 79027
Subject: Re: Xilinx makes dreams true :)
From: Juha Turunen <jtt7665@maa2.cc.lut.fi>
Date: 11 Feb 2005 15:05:16 GMT
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> "Ziggy" <Ziggy@TheCentre.com> schrieb im Newsbeitrag
> news:bvNNd.24610$C24.2729@attbi_s52...
>> Antti Lukats wrote:
>> >>Whops :) Hey we all do silly things..
> [snip]
>> Sounds like a more current C-1 board.. It Also sounds cool.
> 
> HAHA! I do have a C-1 !! Was one of the first one to buy and get it LOOONG
> time ago. It's still collecting dust. I did something with it, but its full
> of design mistakes and it was too-old (component wise) before it was
> announced. 

What kind of design errors does it have?

Juha

-- 
Juha Turunen (turunen(at)iki.fi) elpuri@IRC | The problem with the global
Torikatu 5A4, 53100 Lappeenranta, Finland   |  village are all the global
GSM: 040-7092525, http://iki.fi/turunen/    |   village idiots.

Article: 79028
Subject: Re: second flop in asyn reset distribution
From: "Ansgar Bambynek" <a.bambynek_xxx_@avm.de>
Date: Fri, 11 Feb 2005 16:10:45 +0100
Links: << >>  << T >>  << A >>
Hi,

there is an interesting paper about this topic.
It includes various reset strategies and should clarify your doubts.

It can be found at the following url:
http://www.sunburst-design.com/papers/

HTH

Ansgar

--
Attention please, reply address is invalid, please remove "_xxx_" ro reply
"fpgabuilder" <fpgabuilder-news@yahoo.com> schrieb im Newsbeitrag
news:1107990759.754345.93630@l41g2000cwc.googlegroups.com...
> Ok!  From all the previous topic and other resources on the net I see
> following ckt touted to work for distributing async resets.
>
> always@(posedge clk or negedge ext_reset_l)
>   if(!ext_reset_l)
>      int_reset_l <= 2'b00;
>   else
>      begin
>      int_reset_l[0] <= 1'b1;
>      int_reset_l[1] <= int_reset_l[0];
>      end
> end
> assign chip_reset_l = int_reset_l[1];
>
> My questions is -
> What happens if the second flop (int_reset_l[1]) goes metastable  or
> if it cannot then why?
>
> I cannot understand why so many have recommended the above ckt. as a
> solid form of negating async reset syncly!?
>
> e.g. http://i.cmpnet.com/deepchip/downloads/cliff_resets.zip
>
> I would appreciate it much if someone can educate me on this?
> TIA.
>



Article: 79029
Subject: Why are the NIOS toolchain sources removed from Altera's ftp?
From: Jedi <me@aol.com>
Date: Fri, 11 Feb 2005 15:21:38 GMT
Links: << >>  << T >>  << A >>
Any reason Altera removed their NIOS2 GNU gcc/binutils sources
from their ftp server?

Before they supplied the login information and path on their
website for recompiling the NIOS toolchain (without any
documentation of course ;o) and now the direcotries are
empty...

Since I only have NIOS2 for Windows platform transferring
the sources is:

1. PITA due to DOS files
2. tweaking involved for compiling on UNIX hosts
    since it does't like --target=nios2-elf as under
    Cygwin environment.



rick


Article: 79030
Subject: Re: ISE and IEEE.Fixed_pkg (fixed point math for synth?)
From: "Jezwold" <edad3000@yahoo.co.uk>
Date: 11 Feb 2005 07:46:23 -0800
Links: << >>  << T >>  << A >>
I don't know of any synthesis tool which supports fixed or floating
point at the moment.
You could write your own fixed point representation which will
synthesise.


Article: 79031
Subject: Re: second flop in asyn reset distribution
From: "fpgabuilder" <fpgabuilder-news@yahoo.com>
Date: 11 Feb 2005 07:48:23 -0800
Links: << >>  << T >>  << A >>
Thanks everyone.

Well,  I guess the question I have is why is that reset is related ot
clock only when d input is changing?  Can the inverters in the second
flop not go metastable when the reset changes but d input does not?
AFAIK, this would depend on how the ff is constructed.  But the most
basic FF that I have studied in past have set and preset input in the
feedback loop of the master latch part of the FF.

BTW, Ansgar, thanks for the link.  Actually the paper that I reference
in my post is the by the same authors Wills and Cummings, as pointed
out in your post and when I looked previously there it was the same and
did help answer my question.


Article: 79032
Subject: Re: ISE and IEEE.Fixed_pkg (fixed point math for synth?)
From: ptkwt@aracnet.com (Phil Tomson)
Date: 11 Feb 2005 16:01:15 GMT
Links: << >>  << T >>  << A >>
In article <1108136783.695698.36550@g14g2000cwa.googlegroups.com>,
Jezwold <edad3000@yahoo.co.uk> wrote:
>I don't know of any synthesis tool which supports fixed or floating
>point at the moment.
>You could write your own fixed point representation which will
>synthesise.
>

Actually, I was told that the ieee.fixed_pkg works with Altera, Mentor and 
Synplicity synthesis tools (as long as you comment out the alias 
statements in it).  IIRC synopsys was also on the list...  But ISE was 
missing from the list.  

Phil


Article: 79033
Subject: Re: Variable phase shift on Spartan3 DCMs. Does it work?
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 11 Feb 2005 16:54:28 GMT
Links: << >>  << T >>  << A >>
If the simulation is showing many cycles between the phase_inc or phase_dec
to the completion of the phase adjustment, you may be good from all the
investigations I did before.

I thought there were something like 89 DLL cycles required before the phase
adjustment was "complete" and the next adjustment would occur.  With a 100
MHz clock and 3 MHz adjustment rate, that doesn't mesh.

I was hoping someone with a greater knowledge of the DLLs and DCMs across
the families might comment on the number of cycles required.

Anyone?


"Ray Andraka" <ray@andraka.com> wrote in message
news:YCUOd.84010$Tf5.6765@lakeread03...
> Austin Lesea wrote:
> Peter, can you get me Virtex4 for under $12?  If so, I'll gladly use
> that instead.   Target device is a spartan3-50 for cost reasons.  Syms,
> as Austin noted, DSS is not in S3.  Clock looks like it will be about
> 100 MHz, and I'll be bumping the phase up by a quarter cycle in 64
> increments.  Will be using the 0 and 90 clk outs, both edges to get
> measurements in each phase quadrant to keep the number of measurements
> reasonable. (Simulation works fine on it, so as long as the simulation
> matches the hardware, it will be OK).  Thanks.
>
> -- 
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 79034
Subject: Re: Writing IP-Cores while sleeping ;)
From: weingart@cs.ualberta.ca (Tobias Weingartner)
Date: Fri, 11 Feb 2005 17:16:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <mr3Pd.585$ss.29@newsfe1-gui.ntli.net>, Kryten wrote:
> 
> However, if the card gets the FPGA bit file re-written on a PC then 
> returned, the CPLD hardware method might have to send megabytes of data 
> before the FPGA sees the sync word. A micro-based method might be able to 
> search a FAT to find a particular-named file, though obviously this is a 
> non-trivial job unless you have some experience with FAT already. Anyone got 
> any PD FAT source code in C? 

I'm sure there are others, but OpenDOS, OpenBSD, NetBSD, FreeBSD, Linux,
and such do have farious versions of FAT code.  Also, I seem to remember
a number of MP3 type projects out there with FAT code.

-- 
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax

Article: 79035
Subject: Re: C program to big for microblaze?
From: "Clemens Ragger" <carlsberg@gmx.at>
Date: Fri, 11 Feb 2005 17:21:00 -0000
Links: << >>  << T >>  << A >>
Thanks for all your hints

But increasing the BRAM was enough, so everything is working properly now!

Ciao 



Article: 79036
Subject: Re: ProAsic3 (PA3)
From: weingart@cs.ualberta.ca (Tobias Weingartner)
Date: Fri, 11 Feb 2005 17:21:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <cuhmtn$29v$03$1@news.t-online.com>, Antti Lukats wrote:
> 
> 600E is supported by free tools, 600 not :)

Which free tools?  :-)

-Toby.

-- 
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax

Article: 79037
Subject: Re: ProAsic3 (PA3)
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 11 Feb 2005 18:29:59 +0100
Links: << >>  << T >>  << A >>

"Tobias Weingartner" <weingart@cs.ualberta.ca> schrieb im Newsbeitrag
news:slrnd0pqc5.ldf.weingart@irricana.cs.ualberta.ca...
> In article <cuhmtn$29v$03$1@news.t-online.com>, Antti Lukats wrote:
> >
> > 600E is supported by free tools, 600 not :)
>
> Which free tools?  :-)
>
> -Toby.

actels tools (free versions) support the smallest of each family
600E is smalles of PA3E :)
for the non-E only the very small are supported by the free stuff
well actually nothing is supported as the current Libero/Designer
that has PA3 support as advertized doesnt actually generate
programming files for any of the PA3 at all, so nothing is supported
that both for free tools users as for paid licensees

Antti



Article: 79038
Subject: Re: Variable phase shift on Spartan3 DCMs. Does it work?
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 11 Feb 2005 09:33:08 -0800
Links: << >>  << T >>  << A >>
John,
As I said, maybe the "FACTORY_JF" thing helps. Is it in the Spartan 3? From
Answer 13756 :-

2. Increase the FACTORY_JF setting to 'FFFF. The DCM updates its taps
approximately every twenty input clocks when the "FACTORY_JF" attribute is
set to 0xFFFF. (The default settings of 0xC080h result in updates that occur
much more slowly.) Note that a well-decoupled and stable power supply is the
preferred solution.
Increasing the FACTORY_JF setting may introduce a small amount of jitter
(~30 ps) because the DCM frequently updates its delay line. (This is why
FACTORY_JF is not set to the maximum value by default.) If the power supply
is unstable, the phase error introduced may be much bigger than the extra
jitter introduced; therefore, increasing the FACTORY_JF setting may improve
the design.

Cheers, Syms.
p.s. I see Xilinx have now got a Google search on their website. It seems to
work much better than the regular search!

"John_H" <johnhandwork@mail.com> wrote
> I thought there were something like 89 DLL cycles required before the
phase
> adjustment was "complete" and the next adjustment would occur.  With a 100
> MHz clock and 3 MHz adjustment rate, that doesn't mesh.
>
> I was hoping someone with a greater knowledge of the DLLs and DCMs across
> the families might comment on the number of cycles required.
>
> Anyone?



Article: 79039
Subject: Re: Variable phase shift on Spartan3 DCMs. Does it work?
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 11 Feb 2005 09:44:02 -0800
Links: << >>  << T >>  << A >>
John,

I used to have the numbers written down somewhere.  But that isn't the 
point.

I believe it was something like so many clocks (86 seems to be what I 
remember from V2)from the CLKIN domain, followed by three clocks in the 
PSCLK domain.  It is non-deterministic, hence the reason for the PSDONE 
bit:  some shifts do not require all the clocks.  There is basically a 
mathematical operation going on here -- we multiply the desired phase 
counter serially (8 bits, or a fraction of 256, where 256/256 = one 
whole period) by the number of taps presently used ot hold a whole 
period.  That then tells us the tap location of the desired phase.

It is recommended (required) that you wait for PSDONE.  In subsequent 
versions, there are slight differences in this logic to do the math 
(clock cycles per update), so if I told you a number, and you used it, 
you would probably break in a future version of the DCM in a new family 
(like V4).  Wait for PSDONE, and then everything is gauranteed to work.

I know the simulation model is a rough algorithmic version of what 
really happens, but I wouldn't count on it to be the actual 
representation of the "right" number of cycles, as it will not behave 
like a serial arithmetic multiplier.

So, do not use a fixed number of cycles.  That isn't what we gaurantee. 
  We gaurantee that PSDONE tells you that it is done shifting.

It will take fewer clocks (on average, depending on the values of where 
the taps are for one full period, and where you are shifting to/from) 
than the total number to do the arithmetic, so any number I give you 
will change from family to family, and doesn't help anyway (as it 
represents the maximum, only).

Austin

John_H wrote:
> If the simulation is showing many cycles between the phase_inc or phase_dec
> to the completion of the phase adjustment, you may be good from all the
> investigations I did before.
> 
> I thought there were something like 89 DLL cycles required before the phase
> adjustment was "complete" and the next adjustment would occur.  With a 100
> MHz clock and 3 MHz adjustment rate, that doesn't mesh.
> 
> I was hoping someone with a greater knowledge of the DLLs and DCMs across
> the families might comment on the number of cycles required.
> 
> Anyone?
> 
> 
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:YCUOd.84010$Tf5.6765@lakeread03...
> 
>>Austin Lesea wrote:
>>Peter, can you get me Virtex4 for under $12?  If so, I'll gladly use
>>that instead.   Target device is a spartan3-50 for cost reasons.  Syms,
>>as Austin noted, DSS is not in S3.  Clock looks like it will be about
>>100 MHz, and I'll be bumping the phase up by a quarter cycle in 64
>>increments.  Will be using the 0 and 90 clk outs, both edges to get
>>measurements in each phase quadrant to keep the number of measurements
>>reasonable. (Simulation works fine on it, so as long as the simulation
>>matches the hardware, it will be OK).  Thanks.
>>
>>-- 
>>--Ray Andraka, P.E.
>>President, the Andraka Consulting Group, Inc.
>>401/884-7930     Fax 401/884-7950
>>email ray@andraka.com
>>http://www.andraka.com
>>
>> "They that give up essential liberty to obtain a little
>>  temporary safety deserve neither liberty nor safety."
>>                                          -Benjamin Franklin, 1759
>>
>>
> 
> 
> 

Article: 79040
Subject: Re: ROM inference in Spartan3
From: "KCL" <kclo4_NO_SPAM_@free.fr>
Date: Fri, 11 Feb 2005 20:50:17 +0100
Links: << >>  << T >>  << A >>
Why do you want to use negative indice?? it's the first time i saw such 
thing
and so does it work if you use positive indice??


"Phil Tomson" <ptkwt@aracnet.com> a écrit dans le message de news: 
cui1g701ovi@enews2.newsguy.com...
> In article <cufvla02a24@enews2.newsguy.com>,
> Phil Tomson <ptkwt@aracnet.com> wrote:
>>
>>This page:
>>http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/xst/xst0026_5.html#wp325264
>>
>>shows some templates for ROM inference in Spartan3 using Xilinx's ISE
>>software.
>>
>>One of the templates is:
>>  library ieee;
>>  use ieee.std_logic_1164.all;
>>  use ieee.std_logic_unsigned.all;
>>  entity rominfr is
>>    port (
>>        clk  : in std_logic;
>>        en   : in std_logic;
>>        addr : in std_logic_vector(4 downto 0);
>>        data : out std_logic_vector(3 downto 0)
>>        );
>>  end rominfr;
>>  architecture syn of rominfr is
>>    type rom_type is array (31 downto 0) of std_logic_vector (3 downto 0);
>>    constant ROM : rom_type :=
>>   ("0001","0010","0011","0100","0101","0110","0111","1000","1001","1010"
>>,"1011","1100","1101","1110","1111","0001","0010","0011","0100","0101"
>>,"0110","0111","1000","1001","1010","1011","1100","1101","1110","1111" );
>>  begin
>>    process (clk)
>>      begin
>>       if (clk'event and clk = '1') then
>>          if (en = '1') then
>>              data <= ROM(conv_integer(addr);
>>          end if;
>>       end if;
>>    end process;
>>  end syn;
>>
>>
>>My question is: are they types of the inputs and outputs important for the
>>software to infer the ROM?  For example, could I have:
>>
>>
>>  entity rominfr is
>>    port (
>>        clk  : in std_logic;
>>        en   : in std_logic;
>>        addr : in std_logic_vector(9 downto 0);
>>        data : out ufixed(0 downto -17) -- ufixed is fixed point
>>                                        --type from:
>>        --http://www.eda.org/vhdl-200x/vhdl-200x-ft/packages/files.html
>>        );
>>  end rominfr;
>>
>>Would the ROM still be inferred because I didn't use std_logic_vector on
>>the data output?  Just wondering how strict the template must be adhered
>>to.
>>
>>
>>There are conversion routines to go to/from std_logic_vector<=>ufixed,
>>however I'd prefer to keep the output of the ROM in ufixed format if
>>possible.
>>
>
> FYI: the line:
>  data : out ufixed(0 downto -17)
>
> Causes the following error:
>  ERROR:Xst:1548 - c:/phil/vhdl/svm/../lookuptable.vhd line 13: Negative
> range in type of signal <data> is not supported.
>
> So looks like you can't use a ufixed (with negative indices ) in a port
> signal, anyway.
>
> Phil 



Article: 79041
Subject: Re: Variable phase shift on Spartan3 DCMs. Does it work?
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 11 Feb 2005 20:00:39 GMT
Links: << >>  << T >>  << A >>
So, bottom line, the simulation might not provide 100% results for PSDONE
but should give a rough approximation.
33 cycles at a CLKIN of 100 MHz may not be enough.
The algorithm Ray Andraka produces should be based on PSDONE for minimum
phase update step size.

Thanks.


"Austin Lesea" <austin@xilinx.com> wrote in message
news:cuiqt2$ee61@cliff.xsj.xilinx.com...
> John,
>
> I used to have the numbers written down somewhere.  But that isn't the
> point.
>
> I believe it was something like so many clocks (86 seems to be what I
> remember from V2)from the CLKIN domain, followed by three clocks in the
> PSCLK domain.  It is non-deterministic, hence the reason for the PSDONE
> bit:  some shifts do not require all the clocks.  There is basically a
> mathematical operation going on here -- we multiply the desired phase
> counter serially (8 bits, or a fraction of 256, where 256/256 = one
> whole period) by the number of taps presently used ot hold a whole
> period.  That then tells us the tap location of the desired phase.
>
> It is recommended (required) that you wait for PSDONE.  In subsequent
> versions, there are slight differences in this logic to do the math
> (clock cycles per update), so if I told you a number, and you used it,
> you would probably break in a future version of the DCM in a new family
> (like V4).  Wait for PSDONE, and then everything is gauranteed to work.
>
> I know the simulation model is a rough algorithmic version of what
> really happens, but I wouldn't count on it to be the actual
> representation of the "right" number of cycles, as it will not behave
> like a serial arithmetic multiplier.
>
> So, do not use a fixed number of cycles.  That isn't what we gaurantee.
>   We gaurantee that PSDONE tells you that it is done shifting.
>
> It will take fewer clocks (on average, depending on the values of where
> the taps are for one full period, and where you are shifting to/from)
> than the total number to do the arithmetic, so any number I give you
> will change from family to family, and doesn't help anyway (as it
> represents the maximum, only).
>
> Austin



Article: 79042
Subject: Re: doubt on configuring FPGA
From: "Gabor" <gabor@alacron.com>
Date: 11 Feb 2005 12:19:14 -0800
Links: << >>  << T >>  << A >>

Neo wrote:
> read the manual and set the jumper switches M1,M2,M3.

One more thing to do in the 17xxx series PROMs.  There is
a reset polarity bit in the prom which is *NOT* part of the
binary file you create in impact or prom file formatter.
This must be set to active LOW which is *NOT* the default
setting or your FPGA will not program.  The way to
program this bit depends on your programming equipment.


Article: 79043
Subject: xilinx MGT compatibility?
From: Tullio Grassi <tgrassi@mail.cern.ch>
Date: Fri, 11 Feb 2005 21:41:47 +0100
Links: << >>  << T >>  << A >>
Hi,

 can the MGT of Virtex-4FX talk to the
MGT of Virtex-2Pro (XC2VPX) ?
Any experience or problems ?

 Tullio 
 

Article: 79044
Subject: Re: Sending text from fpga to printer
From: "Marco" <marcotoschi@email.it>
Date: Fri, 11 Feb 2005 22:09:54 +0100
Links: << >>  << T >>  << A >>
I should send text to a parallel printer.

What is a centronics interface?


"Roel" <electronics_designer@hotmail.com> wrote in message
news:cuglno$51a$1@news2.zwoll1.ov.home.nl...
> Marco wrote:
> > Is it possible?
> >
> >
> It's very simple in case of a printer having a centronics interface.
> Even graphics can be done easily after sending the right commands.
>
> In case of a USB printer you will need a USB host. Implementing that in
> an FPGA will be much more difficult, so buy an old fashion HP500 Deskjet
> from Ebay and use that one (:
>
> Best Regards,
> Roel
>
>



Article: 79045
Subject: Re: second flop in asyn reset distribution
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 11 Feb 2005 15:26:41 -0600
Links: << >>  << T >>  << A >>
>Well,  I guess the question I have is why is that reset is related ot
>clock only when d input is changing?  Can the inverters in the second
>flop not go metastable when the reset changes but d input does not?
>AFAIK, this would depend on how the ff is constructed.  But the most
>basic FF that I have studied in past have set and preset input in the
>feedback loop of the master latch part of the FF.

Metastability requires a race condition.  You have to be interested
in whether the FF will go from a 0 to a 1 or stay at a 0.  (or the
other way around)

There is such a race condition when reset goes away if you are
trying to clock a 1 into a FF.  If you are trying to clock in
a 0, there is no problem - you get 0 or 0 so it doesn't matter.

The second FF in the case being discussed is the 0 to 0 case.

The first FF might go metastable.  The whole point of this
discussion is to move the metastability considerations from
all over the FSM to one concentrated place where the designer
can check it carefully by hand.  The tools don't help much,
at least not yet.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 79046
Subject: Re: Writing IP-Cores while sleeping ;)
From: Eric Smith <eric@brouhaha.com>
Date: 11 Feb 2005 13:57:11 -0800
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> <snip FPGA bootloader for SD Card>

Kryten wrote:
> Wouldn't this be better done by a small micro (e.g. AVR) though?

It could be, but it would be slower and more expensive.

> These could be smaller than the 9536 chips.

The 9536XL is amazingly cheap.

> I'm also looking for a system where the main micro can use the SD card after 
> booting.

Shouldn't be any problem with that.  Just tie the SD to both the
CPLD (or uP) and the FPGA, and have the CPLD (or uP) put its SD
interface pins into high-Z once the config is done.

> However, if the card gets the FPGA bit file re-written on a PC then 
> returned, the CPLD hardware method might have to send megabytes of data 
> before the FPGA sees the sync word. A micro-based method might be able to 
> search a FAT to find a particular-named file,

True.  A point in favor of the microcontroller.

Though if you don't mind writing special code for the PC, you can
have it always arrange for the FPGA bit file to be a single contiguous
chunk near the start of the SD.

In fact, once you've got it there the first time, you should be able
to rewrite the bit file without it moving around.

> though obviously this is a 
> non-trivial job unless you have some experience with FAT already. Anyone got 
> any PD FAT source code in C? 

Yes, RDCF2 by Philip J. Erdelsky:
    http://alumnus.caltech.edu/~pje/rdcf2.txt

I wish I'd known about RDCF2 when I wrote the boot ROM for the ReplayTV.
I wrote my own read-only FAT filesystem for it.  (Used for software
development only; the ReplayTV does not use FAT.)

Eric

Article: 79047
Subject: Re: Writing IP-Cores while sleeping ;)
From: Eric Smith <eric@brouhaha.com>
Date: 11 Feb 2005 13:58:32 -0800
Links: << >>  << T >>  << A >>
Kryten wrote:
> Anyone got any PD FAT source code in C? 

Tobias Weingartner wrote:
> I'm sure there are others, but OpenDOS, OpenBSD, NetBSD, FreeBSD, Linux,
> and such do have farious versions of FAT code.

None of which are public domain.  The BSD licensed code is closest.  But
code for either a BSD or Linux kernel will be hard to adapt to a tiny
microcontroller.

Article: 79048
Subject: Re: Altera's Megafunction altaccumulator
From: "Subroto Datta" <sdatta@altera.com>
Date: 11 Feb 2005 14:18:56 -0800
Links: << >>  << T >>  << A >>

Christos wrote:
> Hi,
>
> It seems that it is not possible to instantiate an accumulator with
the
> Megawizard plug-in which has an input wider than 33 bits.
>
> If you set the input wider than 33 bits it gives the following error:
>
>
---------------------------------------------------------------------------
> Microsoft Visual C++ Runtime Library
>
> Runtime Error!
>
> Program: C:\altera\quartus41\bin\mega_altaccumulate.exe
>
> This application has requested the Runtime to terminate it in an
unusual
> way,
> Please contact the application's support team for more information.
>
----------------------------------------------------------------------------
> --
>
> I have winXP sp1 running QuartusII 4.1 sp2 full version.
> I have tried this to other PCs with similar configuration and still
did not
> work.
> Finally, I have read all help files with megawizard and the
altaccumulate
> and have not seen anywhere stating this limitation.
>
> Thanks to anyone which can help.
>

Hi Christos,

  We tested the altaccumulate megafunction with a size of 34 bits and
with all other settings as default, the problem mentioned was not
encountered. Would it be possible to email me the settings that were
chosen in the Megawizard that were no-default? That would help us
reproduce the problem.

- Subroto Datta
Altera Corp.

> Christos


Article: 79049
Subject: Re: ISE versus Modelsim inconsistency and attribute definition
From: Elder Costa <elder.costa@terra.com.br>
Date: Fri, 11 Feb 2005 20:59:53 -0200
Links: << >>  << T >>  << A >>
Brian Davis wrote:
> Elder Costa wrote:
> 
>>I tried to do it as in the snippet bellow and I get compilation error:
> 
> 
> There seem to be various typos in those code snippets you posted-
> did you cut and paste, or re-type them, into your post?

Cut and pasted. The only real typo was the extra semicolon Neo pointed 
out (Xst just ignores it :-(  ). If you mean the exchanged As and Bs, 
that was due me not willing to change the VHDL code in the hierarchy 
this module is par of.

> 
> Also, an important BRAM safety tip:
> 
> A variable width dual port spanning multiple BRAMs needs
> reindexing of the wider port bits to do what you intend.

I guess I learned that today the worst way. It took me a couple of hours 
looking at simulation results to figure it out.

Thanks & regards.

Elder



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