Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hello, I a newer to vhdl. I am trying to change my algorithm form
matlab to vhdl. I met RAMs conflict when I did it.
***********************************************************
library IEEE;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
library unisim;
use unisim.vcomponents.all;
entity dcdtest3 is
generic (Nit: integer:=20000; H: integer :=1; Mb: integer :=6);
port
( clk: in std_logic;
en: in std_logic;
b: in std_logic_vector(15 downto 0);
r: in std_logic_vector(15 downto 0);
dout1: out std_logic_vector(15 downto 0);
dout2: out std_logic_vector(15 downto 0));
end dcdtest3;
architecture behaviour of dcdtest3 is
function maxfunction( arg1, arg2, arg3: std_logic_vector (15 downto
0)) return std_logic_vector ;
type ram_type1 is array (0 to 3) of std_logic_vector(15 downto 0);
signal ramb : ram_type1 :=(others =>(others=>'0'));
signal ramh : ram_type1 :=(others =>(others=>'0'));
signal ramrtmp: ram_type1 :=(others =>(others=>'0'));
type ram_type2 is array (0 to 15) of std_logic_vector (15 downto 0);
signal ramr : ram_type2:=(others =>(others=>'0'));
signal douts1: std_logic_vector(15 downto 0) :=(others=>'0');
signal douts2: std_logic_vector(15 downto 0) :=(others=>'0');
signal trigger: std_logic :='0';
begin
dout1<=douts1;
dout2<=douts2;
*************************write data into
RAMB******************************
writeramb: process(clk)
variable indexb: integer range 0 to 4 :=0;
variable web: std_logic :='1';
variable reb : std_logic :='0';
begin
if clk'event and clk='1' then
if web='1' then
ramb(indexb)<=b;
indexb:=indexb+1;
if indexb=4 then
indexb :=0;
web :='0';
end if;
end if;
end if;
end process;
*********************write data into
RAMR******************************************
writeramr: process(clk)
variable indexr: integer range 0 to 16 :=0; .
variable wer: std_logic :='1';
begin
if clk'event and clk='1' then
if wer='1' then
ramr(indexr)<=r;
end if;
if indexr=0 then
ramrtmp(0) <= ramr(indexr);
elsif indexr=5 then
ramrtmp(1) <=ramr(indexr);
elsif indexr=10 then
ramrtmp(2) <=ramr(indexr);
elsif indexr=15 then
trigger <='1'; ***********************
ramrtmp(3) <=ramr(indexr);
end if;
indexr :=indexr+1;
if indexr =16 then
indexr :=0;
wer :='0';
end if;
end if;
end process;
******************************Algorithm*************************************
Algorithm: process (trigger, clk)
............................................................
begin
if trigger ='1' then
if clk'event and clk='1' then
............................................................
........................................................
-- ramb(0) <=ramb(index)+ conv_std_logic_vector(ramrtemp,16);
-- ramb(1) <=ramb(index)+ conv_std_logic_vector(ramrtemp1,16);
-- ramb(2) <=ramb(index)+ conv_std_logic_vector(ramrtemp2,16);
-- ramb(3) <=ramb(index)+ conv_std_logic_vector(ramrtemp3,16);
...........................................................................
end if;
end if;
***************************************************************************************
Though I put three process here,I want the algorithm process to be
executed after all the data sent into the RAMs. I put 'Trigger' as one
of sensitivity parameters in process Algorithm.
RAMr works normally but the RAMb always have conflict problem (For
example ,the data 0000000000000001 saved RAMB become 000000000000000X).
When I removed the codes(ramb(0)<=.....) whick is concerned with RAMb
in the process of Algorithm. Then there is not conflict problem anymore
in RAMb.
My question is why Algorithm process effects the WriteRAMb process.
Because I set 'Trigger=1' when the all data were sent into RAMs.Then
the process Algorithm is activated.
Hopefully you can understand the problem what i described here and give
some suggestions. Thanks
Zhi
Article: 103951-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 GaLaKtIkUs™ wrote: > I wanted to use Icarus but I was confronted to a big problem (as a user > of Xilinx): in the simlation libraries there are specify blocs and > Icarus verilog doesn't support them and there are no shoft term plans > to support them. Great was my deception (as open source enthusiast) but > now I'm obliged to use a commercial simulator. It doesn't matter. The specify blocks are ignored and simulation works just fine. You will not be able to do back-annotated post- par timing simulations, but functional simulations work just fine. I (and my day job co-workers) use Icarus Verilog for Xilinx work all the time. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkf+CrPt1Sc2b3ikRAilYAJ0X1fDeKL2aXJKZosT+S+D6ri5jjgCePmLp fnPgNspKMlUVaG4N5Kcag1A= =IkVF -----END PGP SIGNATURE-----Article: 103952
"Tim" <tim@rockylogiccom.noooospam.com> writes: > http://www.cl.cam.ac.uk/~swm11/research/papers/iccd1998.pdf seems relevant. Thanks, Tim; that was actually the same paper I posted in my question. - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 103953
Mike Treseler <mike_treseler@comcast.net> writes:
> Adam Megacz wrote:
>> Any pointers? I've come across a rather depressing paper concluding
>> that this isn't possible on the (extremely old) XC4000, but I'm sort
>> of hoping against hope that things may have changed
> They haven't.
> Adding a clock and using standard
> synchronization techniques will be
> ten times easier that any alternative.
Thanks, Mike.
One more question: is there any serious disadvantage to using a
clocked DFF directly as an "arbiter" rather than generating some
artificial ring-oscillator-clock?
The scenario I'm thinking of is to have both the D and CLK lines into
the FF low, and then both of them rise. If CLK rises first, then Q=0;
if D rises first then Q=1. This acts as a very crude arbitration
primitive -- not the entire solution [*].
The only disadvantage I can think of is that the oscillator-clock
arbiter's MTBF is unrelated to the timing of the inputs you hand it
(the clock signal is effectively "random" compared to the async input,
so the probability of a setup/hold failure is a nicely distributed
random variable). Using my scheme, the MTBF depends on how often you
have "close" arbitrations -- if you have lots of them it has a worse
MTBF (than an oscillator-clock), if you have fewer of them it has a
better MTBF (than an oscillator-clock).
- a
[*] Beyond this I would have to OR each input signal with a delayed
fanout of the other signal, so that one of them could "win" even
if the other one never showed up. Additionally, I'd probably want
at least two layers of DFFs -- so that the second layer can mask
any fluctuations on the output of the first DFF. But racing CLK
against D is really the only part I have doubts about.
--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380
Article: 103954All of the asynchronous-circuits-on-Xilinx work I've found to date has involved either the XC6200 or jbits (Virtex-2-nonpro and earlier only). Is anybody aware of any self-timed/async work using Spartan-3 or Virtex-IIPro/4/5? - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 103955
Adam, as I explained earlier: You are trying to detect something that is inherently meaningless. Since unknown delay differences "in front of" your circuit are much larger than the inherent ambiguity of the detector, it is meaningless to fight the small metastability window, when you have perhaps nanoseconds, and definitely pioseconds of funcertainty elswhere. You can get a clear and definitive anwer with a few ns delay, but it may not be the right answer, whtever "right" means. Nobody can even define that... Peter Alfke ======================= Adam Megacz wrote: > Mike Treseler <mike_treseler@comcast.net> writes: > > Adam Megacz wrote: > >> Any pointers? I've come across a rather depressing paper concluding > >> that this isn't possible on the (extremely old) XC4000, but I'm sort > >> of hoping against hope that things may have changed > > > They haven't. > > Adding a clock and using standard > > synchronization techniques will be > > ten times easier that any alternative. > > Thanks, Mike. > > One more question: is there any serious disadvantage to using a > clocked DFF directly as an "arbiter" rather than generating some > artificial ring-oscillator-clock? > > The scenario I'm thinking of is to have both the D and CLK lines into > the FF low, and then both of them rise. If CLK rises first, then Q=0; > if D rises first then Q=1. This acts as a very crude arbitration > primitive -- not the entire solution [*]. > > The only disadvantage I can think of is that the oscillator-clock > arbiter's MTBF is unrelated to the timing of the inputs you hand it > (the clock signal is effectively "random" compared to the async input, > so the probability of a setup/hold failure is a nicely distributed > random variable). Using my scheme, the MTBF depends on how often you > have "close" arbitrations -- if you have lots of them it has a worse > MTBF (than an oscillator-clock), if you have fewer of them it has a > better MTBF (than an oscillator-clock). > > - a > > [*] Beyond this I would have to OR each input signal with a delayed > fanout of the other signal, so that one of them could "win" even > if the other one never showed up. Additionally, I'd probably want > at least two layers of DFFs -- so that the second layer can mask > any fluctuations on the output of the first DFF. But racing CLK > against D is really the only part I have doubts about. > > -- > PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 103956
Stephen Williams wrote: > GaLaKtIkUs™ wrote: >>I wanted to use Icarus but I was confronted to a big problem (as a user >>of Xilinx): in the simlation libraries there are specify blocs and >>Icarus verilog doesn't support them and there are no shoft term plans >>to support them. Great was my deception (as open source enthusiast) but >>now I'm obliged to use a commercial simulator. > > > It doesn't matter. The specify blocks are ignored and simulation > works just fine. You will not be able to do back-annotated post- > par timing simulations, but functional simulations work just fine. > > I (and my day job co-workers) use Icarus Verilog for Xilinx work > all the time. Interesting - can you give some comments on the relative speed / reliability /size of the present Icarus release ? -jgArticle: 103957
johnp wrote:
> Does anyone know if similar clocking is available on the V2Pro parts?
Yes.
> Any pointers to documentation?
Other than XAPP609, I know of:
- the phantom XAPP769 for S3 local clocks
- manual inspection in FPGA Editor
- the perl script in Answer Record 17697 :
How do you determine I/O locations for Local Clock Routing
according to XAPP609?
Also, that DIFF_OUT buffer example code I posted a couple
months ago had some local clocking notes in the comments.
The various flavor DRAM app notes may have a few more tidbits
of information, since the local clocks are used for DQS-like signals.
Brian
Article: 103958backhus wrote: > Hi Mike, > what do you mean with winner? Lowest overall FF count? > Sure, but there was never a doubt about it. > The question was if a state minimzation can be performed with ISE > regardless of the encoding style. > > The Quartus results are quite interesting. > In pseudo_states.pdf we can see the states before(!) minimization. From > the autogenerated diagram it's kind of hard to see that the states build > a decision tree. (Well... tools :-) ) > It's funny to see that S7 and S11 are in double circles unlike the other > States above S6. > The only difference between the double circled states and the single > circled states is, that Y remains constantly '0'. > > The ptd-fsm checks a serial bitstream X for non-BCD tetrades with LSB > first (at S0) and MSB last (at S(>6)), setting the output Y at that moment. > Now what happens in the QUARTUS created FSM when it should branch to S7 > or S11. Does it remain in S3 or S5 for 2 clock cycles? How? > Or has it really kicked away these states, thus running out of > synchronization with the data stream. (I doubt, but who knows.) > May be it goes over states S8 or S12 and does a tricky output decoding. > > At least it does some minimization, even if it wasn't expected that way. > Thank you for presenting these results. > > Best regards > Eilert > > > > Mike Treseler schrieb: > > backhus wrote: > > > >> Mike, interesting result from Quartus. At least it seems to do some > >> optimization. > > > > It may be of academic interest, > > but binary encoding is the clear winner here, > > as it usually is in small cases. > > Even in large cases the difference is > > mostly one of speed, not area. > > > >> Is there anything in the synthesis report that gives information about > >> what exactly was done to the FSM? > > > > looks like it pitched 7 and 11: > > http://home.comcast.net/~mike_treseler/pseudo.pdf > > http://home.comcast.net/~mike_treseler/pseudo_states.pdf > > > > -- Mike Treseler Hi All, First, apologies to Eilert and Mike: Eilert, I posted in haste on Tuesday, not giving full consideration to your original post, thought you were the student, not the instructor, and so the unfortunate RTM comment. Mike, I tried this out at home yesterday on my laptop, and "auto" used to produce one-hots in ISE 6.1, so you were right then. Tommy, when I said "LUT usage increase", I was (wrongly) comparing apples to oranges, i.e., ISE to Quartus. ISE 8.1 gave 10 LUTs (auto, with sequential binary coding) where Quartus gave 13 LUTs. Trying to contribute a little more: Today I tried ISE with "compact" encoding, and it produced a solution w/ 4 FFs, and 6 LUTs. Finally, I tried the "hand" reduction myself. Not using pen/paper, but with an editor, eye-balling for equivalent states, and replacing all equivalent states with the lowest numbered state in an eqiv group. It takes more than one pass, and I ended up with a different final number than the 7 states that Eilert posted (Eilert, since this is a class exercise, I'll send you the final result direct). Putting the final reduced state machine through ISE w/ compact encoding resulted in: 3 FFs, 3 LUTs. (I think XST gave the same speed estimate for both the 4 FF and the 3 FF solution, and I am not going go further and try hand placing and routing) This simple example is a very good demonstration that state reduction can produce dramatic resource reduction: 4 FFs => 3 FFs, 6 LUTs => 3 LUTs. I don't get excited about anything less than a factor of 2 lately, but the LUT results clearly indicate that this can be a very valuable feature for a synthesis tool, in spite of the difficulty reconciling functional sim with post synth sim...after all, the states can remain hidden. It's certainly an easy process algorithmically, given a canonical represention of each state... So I've reversed my opinion, because I'm often wrong, and remain, Just John (aka John Smith (Not to be confused with a certain noisy Viking))Article: 103959
I am trying to connect to the XMDSTUB on the MicroBlaze (MB)
board using ver 8.1.03i EDK (i.e., I have 8.1i EDK and have
upgraded to SP3).
I am building a basic MicroBlaze system: a MicroBlaze (soft-core)
processor, memory, and a UART, as in the following "lab"
document:
http://www.eecg.toronto.edu/~pc/courses/edk/modules/6.1/Lab1.v1.1.pdf
This works for me when I use ver (approx) 6.1, but not when I use
ver 8.1.03i -- on different computers, but I doubt that is the
problem. I moved the same MB, cables, power-bricks, cords, etc.,
between the computers.
Using ver 8.1.03i, I try to follow the directions in that
document as best I can given that the user interface has changed
greatly.
I use the simple counter loop program from the lab. I generate
the Bitstream, generate the libraries, download the bitstream to
the MB board successfully, and run XMD. I get the following:
-----------------------------------------------------------------
Xilinx Microprocessor Debug (XMD) Engine
Xilinx EDK 8.1.02 Build EDK_I.20.4
Copyright (c) 1995-2005 Xilinx, Inc. All rights reserved.
XMD%
Loading XMP File..
Processor(s) in System ::
Microblaze(0) : microblaze_0
Address Map for Processor microblaze_0
(0x00000000-0x0000ffff) dlmb_cntlr dlmb
(0x00000000-0x0000ffff) ilmb_cntlr ilmb
(0x40600000-0x4060ffff) RS232 mb_opb
(0x41400000-0x4140ffff) debug_module mb_opb
Connecting to cable (Parallel Port - LPT1).
Checking cable driver.
Driver windrvr6.sys version = 7.0.0.0. LPT base address = 0378h.
ECP base address = 0778h.
ECP hardware is detected.
Cable connection established.
Connecting to cable (Parallel Port - LPT1) in ECP mode.
Checking cable driver.
Driver xpc4drvr.sys version = 1.0.4.0. LPT base address = 0378h.
Cable Type = 1, Revision = 3.
Setting cable speed to 5 MHz.
Cable connection established.
JTAG chain configuration
--------------------------------------------------
Device ID Code IR Length Part Name
1 0a001093 8 System_ACE
2 01038093 6 XC2V2000
Assuming, Device No: 2 contains the MicroBlaze system
Connected to the JTAG MicroProcessor Debug Module (MDM)
No of processors = 0
JTAG Uart ReadByte timeout
JTAG Uart ReadByte timeout
Unable to sync with stub on board
No response to Debug_SYS_Rst signal (System Reset)
Verify if FPGA is configured correctly or XMDSTUB is running on
Board.
XMD%
-----------------------------------------------------------------
I tried it with both "Enable MicroBlaze Debug Module Interface"
and without -- found on the "Debug" tab of the dialog box
obtained when you double-click on the microblaze_0 instance in
the System Assembly Bus Interface View.
I also tried it with the old .xbd file:
Xilinx_Multimedia_v2_1_0.xbd - the new file is
Xilinx_Multimedia_v2_2_0.xbd at
C:\EDK\board\Xilinx\boards\Xilinx_Multimedia\data
Also I fixed a pin mistake in the data/system.ucf file: D10 is
the pin for user SW0, not for the sys_rst_pin. AH7 as the
sys_rst_pin worked when I did this in ver 6. I changed it to AH7
so that it gets as far as the output above; otherwise it doesn't
even get that far.
Can anyone help me with this?
Thanks.
Article: 103960As I recall, the display is refreshed from a block of memory. By doing 'fills' using the Avnet monitor you can erase or make the screen full brightness. I seem to remember that each pixel might have been four bits, so setting the nibbles between 0 and f set the brightness level. Be sure not to leave it on too long at high brightness as the OLED can 'burn' in. -bh "Andrew Lohbihler" <andrewl@rogers.com> wrote in message news:haCdnUZtzu_FLAzZnZ2dnUVZ_oKdnZ2d@giganews.com... > > "Antti Lukats" <antti@openchip.org> wrote in message > news:e6s84l$nq2$1@online.de... > > "Bluespace Technologies" <bluespace@rogers.com> schrieb im Newsbeitrag > > news:z8ednRZo4eugEgzZnZ2dnUVZ_tGdnZ2d@giganews.com... > >> I'm trying to use the sample pictiva VHDL code from Avnet to drive a mini > >> OLED (OSRAM Pictiva 128x64 pixel) on their test board, to get anything > >> presented (numerical data) on the screen. Has anyone got this device to > >> work, using sample code or other? > >> > >> Is there an alternative way to get numerical data presented to a screen? > >> Assuming I can get VHDL drivers for it. > >> > >> -Andrew > > the original demos including the star wars movie work on the OLED, and as > > there CD has all source I assume its rather simple to use the OLED? Or > > what problems are you having? > > > > Antti > > > Thanks, Where can I get those demos? Are they available online somewhere? > The source code I got from the Avnet website and board CD didn't really help > get me going. > > -Andrew > >Article: 103961
Also, I remember to compile the software and update the bitstream before downloading. james7uw@yahoo.ca wrote: > I am trying to connect to the XMDSTUB on the MicroBlaze (MB) > board using ver 8.1.03i EDK (i.e., I have 8.1i EDK and have > upgraded to SP3). > > I am building a basic MicroBlaze system: a MicroBlaze (soft-core) > processor, memory, and a UART, as in the following "lab" > document: > http://www.eecg.toronto.edu/~pc/courses/edk/modules/6.1/Lab1.v1.1.pdf > > This works for me when I use ver (approx) 6.1, but not when I use > ver 8.1.03i -- on different computers, but I doubt that is the > problem. I moved the same MB, cables, power-bricks, cords, etc., > between the computers. > > Using ver 8.1.03i, I try to follow the directions in that > document as best I can given that the user interface has changed > greatly. > > I use the simple counter loop program from the lab. I generate > the Bitstream, generate the libraries, download the bitstream to > the MB board successfully, and run XMD. I get the following: > > ----------------------------------------------------------------- > Xilinx Microprocessor Debug (XMD) Engine > Xilinx EDK 8.1.02 Build EDK_I.20.4 > Copyright (c) 1995-2005 Xilinx, Inc. All rights reserved. > > XMD% > Loading XMP File.. > Processor(s) in System :: > > Microblaze(0) : microblaze_0 > Address Map for Processor microblaze_0 > (0x00000000-0x0000ffff) dlmb_cntlr dlmb > (0x00000000-0x0000ffff) ilmb_cntlr ilmb > (0x40600000-0x4060ffff) RS232 mb_opb > (0x41400000-0x4140ffff) debug_module mb_opb > > Connecting to cable (Parallel Port - LPT1). > Checking cable driver. > Driver windrvr6.sys version = 7.0.0.0. LPT base address = 0378h. > ECP base address = 0778h. > ECP hardware is detected. > Cable connection established. > Connecting to cable (Parallel Port - LPT1) in ECP mode. > Checking cable driver. > Driver xpc4drvr.sys version = 1.0.4.0. LPT base address = 0378h. > Cable Type = 1, Revision = 3. > Setting cable speed to 5 MHz. > Cable connection established. > > JTAG chain configuration > -------------------------------------------------- > Device ID Code IR Length Part Name > 1 0a001093 8 System_ACE > 2 01038093 6 XC2V2000 > Assuming, Device No: 2 contains the MicroBlaze system > Connected to the JTAG MicroProcessor Debug Module (MDM) > No of processors = 0 > > JTAG Uart ReadByte timeout > JTAG Uart ReadByte timeout > Unable to sync with stub on board > No response to Debug_SYS_Rst signal (System Reset) > Verify if FPGA is configured correctly or XMDSTUB is running on > Board. > > XMD% > ----------------------------------------------------------------- > > I tried it with both "Enable MicroBlaze Debug Module Interface" > and without -- found on the "Debug" tab of the dialog box > obtained when you double-click on the microblaze_0 instance in > the System Assembly Bus Interface View. > > I also tried it with the old .xbd file: > Xilinx_Multimedia_v2_1_0.xbd - the new file is > Xilinx_Multimedia_v2_2_0.xbd at > C:\EDK\board\Xilinx\boards\Xilinx_Multimedia\data > > Also I fixed a pin mistake in the data/system.ucf file: D10 is > the pin for user SW0, not for the sys_rst_pin. AH7 as the > sys_rst_pin worked when I did this in ver 6. I changed it to AH7 > so that it gets as far as the output above; otherwise it doesn't > even get that far. > > Can anyone help me with this? > > Thanks.Article: 103962
"Peter Alfke" <alfke@sbcglobal.net> writes: > Since unknown delay differences "in front of" your circuit are much > larger than the inherent ambiguity of the detector, Hi, Peter, I think I may not have stated my request precisely enough. The device does not need to determine which signal "wins the race"; it just needs to unambiguously award the trophy to one of the runners. An arbiter is still an arbiter when you add a delay line to one of its inputs: it still performs the essential function of choosing an unambiguous winner, even if it favors one side over the other. - aArticle: 103963
Maroc wrote: > Hi all, > > I implemented a bidirectional bus using tristate buffer inside a XPLA3 > device. > The CPLD is interconnected to an external device by this bidirectional > bus. > The problem is that I cannot write or read the contents of external > device. > The timing is correct, I have a doubt: could be possible that the > external device has no such output current to drive a low on the bus > when the bidirectional bus inside the CPLD is in read direction? > Someone know issue about implementation of bidirectional bus using XPL3 > device? There should be a fitter report file, look at that, and see if the eqns look ok for .oe and .io feedback from the pins. You can check drive ability with a multimeter. -jgArticle: 103964
Here's how you would do this in an ASIC (see page 6, top left slide) http://www.cl.cam.ac.uk/Teaching/Lectures/compwoclocks/selftimed.4up.pdf The four transistors on the right basically measure the voltage difference between the two NAND outputs, watching for them to be separated by at least Vth. There's another version where you use high-threshhold gates instead. Obviously you can't reproduce exactly this circuit in an FPGA. I'm just posting this to show the thing I'm trying to imitate. - aArticle: 103965
Adam, if you read the second posting in this thread, that's exactly what I described there. We could have saved ourselves a lot of postings... Peter Alfke Adam Megacz wrote: > Here's how you would do this in an ASIC (see page 6, top left slide) > > http://www.cl.cam.ac.uk/Teaching/Lectures/compwoclocks/selftimed.4up.pdf > > The four transistors on the right basically measure the voltage > difference between the two NAND outputs, watching for them to be > separated by at least Vth. There's another version where you use > high-threshhold gates instead. > > Obviously you can't reproduce exactly this circuit in an FPGA. I'm > just posting this to show the thing I'm trying to imitate. > > - aArticle: 103966
Adam> > Here's how you would do this in an ASIC (see page 6, top left slide) Adam> > http://www.cl.cam.ac.uk/Teaching/Lectures/compwoclocks/selftimed.4up.pdf Peter> Adam, if you read the second posting in this thread, that's exactly Peter> what I described there. We could have saved ourselves a lot of Peter> postings... Hrm, do you mean this posting [below]? This is very, very different from a Seitz Arbiter... without the voltage-differencing, the arbiter can fail (glitch, "change its mind", etc). Peter> If you reduce your requirements to an unambiguous output, even if it is Peter> the "wrong" one (whatever wrong means when things happen essentially Peter> simultaneously) then the problem reminds me of metastability Peter> resolution, which will usually occur in a short time (although Peter> theoretically -but only theoretically- unbounded). Peter> The faster the circuitry, the smaller your "no-man's land" of Peter> uncertainty, and the faster the resolutio. I would, therefore, go with Peter> the fastest LUT-based FPGA. You can imagine which one I have in mind. Peter> So: theoretically it's unsolvable, but you can get very close with Peter> modern circuits... -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 103967
Thank you for your answers. But the fact is that in our electronic department we design development kit boards for main ARM processors used with Win CE ( AT91, NADIA, XSCALE, Samsung 2SC2412 and others .. ) and the associated BSP in our software departement. The idea, here in the FPGA department, is to use the power of the Xilinx's System On Chip capabilities, to offer a custom system like the ones designed for the WIN CE platforms. The optimal way would be to have a synthetizable ARM7/9 core to link it to a SOC in the FPGA. Second way would be to find an ARM core with no peripherals in a external chips and connect it to the FPGA. For now I didn't find anything like this. Stéphane. "sjulhes" <t@aol.fr> a écrit dans le message de news: 449152f8$0$29801$626a54ce@news.free.fr... > Hi, > > We have here real good skills in Windows CE software development in our > software departement and I was wondering if there was any solution to get > an ARM7 or ARM9 core running in a Xilinx FPGA ? > > Any feedbacks ? > > Thanks. > > Stéphane. >Article: 103968
Adam Megacz wrote: > "Peter Alfke" <alfke@sbcglobal.net> writes: >> Since unknown delay differences "in front of" your circuit are much >> larger than the inherent ambiguity of the detector, > > Hi, Peter, > > I think I may not have stated my request precisely enough. The device > does not need to determine which signal "wins the race"; it just needs > to unambiguously award the trophy to one of the runners. > > An arbiter is still an arbiter when you add a delay line to one of its > inputs: it still performs the essential function of choosing an > unambiguous winner, even if it favors one side over the other. If I may ask, what's your application for this ? That reminds me of something I saw recently : PUFs SylvainArticle: 103969
Hi Tommy, your solution is perfectly correct! While the example comes from the script and has 6 states in the end, my (then absent) mind was fixed to the laboratory assignment, which is slightly different and has the mentioned 7 States. Sorry for causing confusion. Best Regards EilertArticle: 103970
Ed McGettigan schrieb: > Antti Lukats wrote: > > "Vhdl.eu" <info@mobile-it.be> schrieb im Newsbeitrag > > news:44917270$0$10467$ba620e4c@news.skynet.be... > >> Hi, > >> > >> Maybe you can consider to go to the FPGA's of ACTEL they have a free ARM > >> core for in there Mixed Signal FPGA: > >> http://www.actel.com/products/arminfusion/ > >> > >> Kind regards, > >> http://www.vhdl.eu > > > > what Actel says "FREE" means 120USD per FPGA for ARM license fee in small > > qty. > > the do not want any small customers at all :( > > I've always wondered how much value was in the Actel ARM the whole announcement > and strategy has seemed strange to me. I just took a look at the CoreMP7 > product brief (http://www.actel.com/documents/CoreMP7_PB.pdf) and on page 5 > there is a list of the max MHz and the number of Tiles that the soft core > takes up. > > Max Freq : 22.714 - 29.699 (Depends on device and if debug is supported) > Tiles : 6,104 - 8,587 (Depends on device and if debug is supported) > Utilization: 26.0% - 99.3% (Depends on device and if debug is supported) > > This seems to be well below the performance level of a Xilinx MicroBlaze or > Altera NIOS-II soft core and extremely below the level of a a Xilinx PowerPC > hard core with a much higher area cost. > > I know that there is niche out there for ARM7 prototypers, but with the > performance and area cost does this even come close to a general market > need? > > Ed McGettigan > -- > Xilinx Inc. The 99.3 utilization is for smalles device the plain core does fit in at all, its only for marketing, the core cant actually be used in that device as there is nothing else as the core that fits. The performance is pretty low as of max clock frequency and the FPGA "resource price" is also huge, so yes it does not actually compete with FPGA processors. ASFAIK Actel is only looking for a few big customers, and maybe a few more occasional customers, but for small or medium volume productst the actual costs of the "free" ARM core are way too high. But what I found VERY VERY interesting is the fact that CoreConsole uses SPIRIT XML standard for the IP parametrization and interconnect description. AnttiArticle: 103971
Andrew Lohbihler schrieb: > "Antti Lukats" <antti@openchip.org> wrote in message > news:e6s84l$nq2$1@online.de... > > "Bluespace Technologies" <bluespace@rogers.com> schrieb im Newsbeitrag > > news:z8ednRZo4eugEgzZnZ2dnUVZ_tGdnZ2d@giganews.com... > >> I'm trying to use the sample pictiva VHDL code from Avnet to drive a mini > >> OLED (OSRAM Pictiva 128x64 pixel) on their test board, to get anything > >> presented (numerical data) on the screen. Has anyone got this device to > >> work, using sample code or other? > >> > >> Is there an alternative way to get numerical data presented to a screen? > >> Assuming I can get VHDL drivers for it. > >> > >> -Andrew > > the original demos including the star wars movie work on the OLED, and as > > there CD has all source I assume its rather simple to use the OLED? Or > > what problems are you having? > > > > Antti > > > Thanks, Where can I get those demos? Are they available online somewhere? > The source code I got from the Avnet website and board CD didn't really help > get me going. > > -Andrew not the resource CD, the oled OPB ip core and some C code is available from inside the uclinux platform demo archive that is available from John Williams website. :) AnttiArticle: 103972
Hi John, you are the second that comes up with a 6 state solution. That made me doubt about my posted code, so I fed it into DesignCompiler and got the same result. I nearly went mad, looking for the mistake when I finally took a look in the mirror, and there it was! :-) I have to apologize. Tommys solution (and yours probably too) is correct. I confused the script exercise (which I posted) with the slightly different lab exercise. The lab exercise reduces to 7 States. The solution to the posted script exercise is in the script anyway (That's why we have created a different version for the lab), and the VHDL version has already been posted by Tommy. If you want to send me your results use this link to get my real email-adress: http://www.i3m.hs-bremen.de/internet/contacts/ After all it was a nice brain teaser, wasn't it? It's correct that more than one pass is needed to do a complete minimization. And now that you have posted some results about saved resources everyone should ask why these algorithms are not available in ISE XST. (I already opened a webcast, since none of the XILINX guys in this Newsgroup wrote any statement) Best Regards Eilert > Finally, I tried the "hand" reduction myself. Not using pen/paper, but > with an editor, eye-balling for equivalent states, and replacing all > equivalent states with the lowest numbered state in an eqiv group. It > takes more than one pass, and I ended up with a different final number > than the 7 states that Eilert posted (Eilert, since this is a class > exercise, I'll send you the final result direct). Putting the final > reduced state machine through ISE w/ compact encoding resulted in: 3 > FFs, 3 LUTs. (I think XST gave the same speed estimate for both the 4 > FF and the 3 FF solution, and I am not going go further and try hand > placing and routing) > > This simple example is a very good demonstration that state reduction > can produce dramatic resource reduction: 4 FFs => 3 FFs, 6 LUTs => 3 > LUTs. I don't get excited about anything less than a factor of 2 > lately, but the LUT results clearly indicate that this can be a very > valuable feature for a synthesis tool, in spite of the difficulty > reconciling functional sim with post synth sim...after all, the states > can remain hidden. It's certainly an easy process algorithmically, > given a canonical represention of each state... > > So I've reversed my opinion, because I'm often wrong, and remain, > Just John > (aka John Smith (Not to be confused with a certain noisy Viking)) >Article: 103973
sjulhes wrote: > Thank you for your answers. > > But the fact is that in our electronic department we design development kit > boards for main ARM processors used with Win CE ( AT91, NADIA, XSCALE, > Samsung 2SC2412 and others .. ) and the associated BSP in our software > departement. > > The idea, here in the FPGA department, is to use the power of the Xilinx's > System On Chip capabilities, to offer a custom system like the ones > designed for the WIN CE platforms. The optimal way would be to have a > synthetizable ARM7/9 core to link it to a SOC in the FPGA. > > Second way would be to find an ARM core with no peripherals in a external > chips and connect it to the FPGA. > > For now I didn't find anything like this. That seems a slightly strange angle to take, as the peripherals are effectively free. Your main choice is ROMless, or on Chip FLASH : and that is decided by your application. Even the tiny ARM, have fast serial ports, that can connect to FPGA. Larger ones, have external memory interfaces, so you could memory map the FPGA onto those. More pins, and slightly better bandwidth. -jgArticle: 103974
Hi,
you made a common mistake. Multiple assignment.
In both processes writeramb and Algorithm you assign values to signalramb.
Your simulator detects this and resolves the conflicting values to 'X'.
Your synthesis tool will generate an error.
Think of processes as integrated circuits. (Their enclosure is Begin and
end) There you would never tie normal (compared to tristate) outputs
together because it may lead to shortening the supply and destruction of
the ICs.
Furthermore, If you want to enable some clocked process better write:
if rising_edge(clk) then
if trigger = '1' then
--do something
end if;
end if;
If you want to intialize your ram, you have to do it in another way.
For example in a single process.
have a nice synthesis
Eilert
ZHI schrieb:
>
> ******************************Algorithm*************************************
> Algorithm: process (trigger, clk)
> ............................................................
> begin
> if trigger ='1' then
> if clk'event and clk='1' then
....
> end if;
> end if;
>
> ***************************************************************************************
> Though I put three process here,I want the algorithm process to be
> executed after all the data sent into the RAMs. I put 'Trigger' as one
> of sensitivity parameters in process Algorithm.
> RAMr works normally but the RAMb always have conflict problem (For
> example ,the data 0000000000000001 saved RAMB become 000000000000000X).
>
> When I removed the codes(ramb(0)<=.....) whick is concerned with RAMb
> in the process of Algorithm. Then there is not conflict problem anymore
> in RAMb.
>
> My question is why Algorithm process effects the WriteRAMb process.
> Because I set 'Trigger=1' when the all data were sent into RAMs.Then
> the process Algorithm is activated.
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