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
On Fri, 10 Dec 2004 22:52:51 +0100, Artenz wrote:
> However, if you try to write vector 't' above with a case or if-else
> (which I had tried before), then you get 4 more LUT1s. Apparently you
> have to spell things out really carefully for XST to have it find the
> optimal solution, especially if you want the MUXF6 in there. Which is too
> bad, because it tends to make the code much harder to read.
Actually, you can use a case(f) for the 't' vector if you disable
automatic mux extraction, resulting in something fairly readable:
module lut_test( a, b, c, f, s );
input [3:0] a, b;
input [1:0] s;
input [1:0] f;
output c;
reg [3:0] t;
wire x0, x1;
// synthesis attribute mux_extract of lut_test is false;
always @(a or b or f )
case(f)
2'd0: t <= a & b;
2'd1: t <= a | b;
2'd2: t <= a ^ b;
2'd3: t <= a & ~b;
endcase
MUXF5 m_1a( .I0(t[0]), .I1(t[1]), .S(s[0]), .O(x0) );
MUXF5 m_1b( .I0(t[2]), .I1(t[3]), .S(s[0]), .O(x1) );
MUXF6 m_2 ( .I0(x0), .I1(x1), .S(s[1]), .O(c) );
endmodule
Article: 76776
Hello folks.
I have implemented the entity bellow by instantciating a dual ported
block RAM with different bus widths (RAMB16_S18_S36 - I am developing
for Virtex II or Spartan 3). Whereas it is relatively simple to do it by
instantiacing the component from Xilinx library, I wonder if there is a
way to code the module so that Xst infers the block RAM. I tried in one
or two ways but it used logic in slices instead of BRAM and it required
a lot of logic for a 1kib RAM. Could somebody give a hint on this? I
looked at Xilinx documentation and couldn't find an example for this
particular problem.
entity gaintab is
Port (
-- ports de acesso do processador
i_ProcAddr : in std_logic_vector(9 downto 0);
i_ProcDataIn : in std_logic_vector(15 downto 0);
i_ProcWr : in std_logic;
i_ProcEn : in std_logic;
i_ProcClk : in std_logic;
o_ProcDataOut : out std_logic_vector(15 downto 0);
-- ports de acesso interno (fpga)
i_FpgaAddr : in std_logic_vector(6 downto 0);
i_FpgaClk : in std_logic;
o_FpgaDataOut : out std_logic_vector(31 downto 0)
);
end gaintab;
TIA.
Elder.
Article: 76777Elder Costa wrote: (snip regarding sin lookup tables) >> It would be more usual to make the number of table entries a power >> of two, such that mod 360 degrees could be done by ignoring high >> order bits. You might see if that works better in your case. > It is not possible in my application, a lock in demodulator at 2.5Msps > using a 125KHz carrier. Well, it could probably be done with a phase accumulator, but if the frequencies really are fixed, yes, the 20 element table is best. -- glenArticle: 76778
On Fri, 10 Dec 2004 14:09:00 -0800, Chris Ebeling wrote:
> Annti,
>
> Your correct this can be done. But your coding style isn't exactly conducive
> to the synthesis of a mux. Case statements are the preferred coding style if
> you want the MUXF5/MUXF6/MUXF# resources to be used. The dedicated
> muxes also roughly correlate to a particular width MUXF5 == 4:1,
> MUXF6 == 8:1. etc.
>
> So if you want to get a MUXF6, at three bit case statement is appropriate:
>
> module lut_test2(a,b,c,f,s);
> input f;
> input [1:0] s;
> input [3:0] a;
> input [3:0] b;
> output c;
>
> //Implicit wires exist
> //wire [3:0] a;
> //wire [3:0] b;
> //wire f;
> //wire [1:0] s;
>
> reg caseout;
> //wire [2:0] sel = {s,f};
>
> always @(s or f or a or b)
> case ({s,f})
> //f is 0
> 3'b000 : caseout = (a[0] & b[0]);
> 3'b010 : caseout = (a[1] & b[1]);
> 3'b100 : caseout = (a[2] & b[2]);
> 3'b110 : caseout = (a[3] & b[3]);
> //f is 1
> 3'b001 : caseout = (a[0] | b[0]);
> 3'b011 : caseout = (a[1] | b[1]);
> 3'b101 : caseout = (a[2] | b[2]);
> 3'b111 : caseout = (a[3] | b[3]);
> endcase
>
> assign c = caseout;
>
> endmodule
Chris,
Thanks for the info. I tried the same method on my slightly more
complicated design:
module lut_test( a, b, c, f, s );
input [3:0] a, b;
input [1:0] s;
input [1:0] f;
output c;
reg c;
always @(a or b or f or s)
case({s, f})
4'b0000: c = a[0] & b[0];
4'b0100: c = a[1] & b[1];
4'b1000: c = a[2] & b[2];
4'b1100: c = a[3] & b[3];
4'b0001: c = a[0] | b[0];
4'b0101: c = a[1] | b[1];
4'b1001: c = a[2] | b[2];
4'b1101: c = a[3] | b[3];
4'b0010: c = a[0] ^ b[0];
4'b0110: c = a[1] ^ b[1];
4'b1010: c = a[2] ^ b[2];
4'b1110: c = a[3] ^ b[3];
4'b0011: c = a[0] & ~b[0];
4'b0111: c = a[1] & ~b[1];
4'b1011: c = a[2] & ~b[2];
4'b1111: c = a[3] & ~b[3];
endcase
endmodule
But this resulted in 8 LUTs, 4xMUXF5, 2xMUXF6, and 1xMUXF7. Is there a way to
write this so it'll fit in 4 LUTs without resorting to instantiating
the MUXF5/MUXF6 manually?
Article: 76779
Nope,
Quote:
But this resulted in 8 LUTs, 4xMUXF5, 2xMUXF6, and 1xMUXF7.
This is exactly what you should expect for a 4 bit select vector
MUXF6 = 8:1, MUXF7 = 16:1.
If you run my example through the tools you can review the results and
see that each (of the 4 LUTs) is already fully unitized with 4 inputs
(f, s(0), A#, B#). So you can't get anything more complex, without
using more logic.
Your example will underutilize the LUT4s, 3 inputs A#,B#,& f.
With the select bits driving MUXF5/MUXF6/MUXF7. So you could
make is still more complicated (add a mask bit for example) and not
use any additional resources.
Chris
Artenz wrote:
> On Fri, 10 Dec 2004 14:09:00 -0800, Chris Ebeling wrote:
>
> > Annti,
> >
> > Your correct this can be done. But your coding style isn't exactly conducive
> > to the synthesis of a mux. Case statements are the preferred coding style if
> > you want the MUXF5/MUXF6/MUXF# resources to be used. The dedicated
> > muxes also roughly correlate to a particular width MUXF5 == 4:1,
> > MUXF6 == 8:1. etc.
> >
> > So if you want to get a MUXF6, at three bit case statement is appropriate:
> >
> > module lut_test2(a,b,c,f,s);
> > input f;
> > input [1:0] s;
> > input [3:0] a;
> > input [3:0] b;
> > output c;
> >
> > //Implicit wires exist
> > //wire [3:0] a;
> > //wire [3:0] b;
> > //wire f;
> > //wire [1:0] s;
> >
> > reg caseout;
> > //wire [2:0] sel = {s,f};
> >
> > always @(s or f or a or b)
> > case ({s,f})
> > //f is 0
> > 3'b000 : caseout = (a[0] & b[0]);
> > 3'b010 : caseout = (a[1] & b[1]);
> > 3'b100 : caseout = (a[2] & b[2]);
> > 3'b110 : caseout = (a[3] & b[3]);
> > //f is 1
> > 3'b001 : caseout = (a[0] | b[0]);
> > 3'b011 : caseout = (a[1] | b[1]);
> > 3'b101 : caseout = (a[2] | b[2]);
> > 3'b111 : caseout = (a[3] | b[3]);
> > endcase
> >
> > assign c = caseout;
> >
> > endmodule
>
> Chris,
>
> Thanks for the info. I tried the same method on my slightly more
> complicated design:
>
> module lut_test( a, b, c, f, s );
> input [3:0] a, b;
> input [1:0] s;
> input [1:0] f;
> output c;
>
> reg c;
>
> always @(a or b or f or s)
> case({s, f})
> 4'b0000: c = a[0] & b[0];
> 4'b0100: c = a[1] & b[1];
> 4'b1000: c = a[2] & b[2];
> 4'b1100: c = a[3] & b[3];
>
> 4'b0001: c = a[0] | b[0];
> 4'b0101: c = a[1] | b[1];
> 4'b1001: c = a[2] | b[2];
> 4'b1101: c = a[3] | b[3];
>
> 4'b0010: c = a[0] ^ b[0];
> 4'b0110: c = a[1] ^ b[1];
> 4'b1010: c = a[2] ^ b[2];
> 4'b1110: c = a[3] ^ b[3];
>
> 4'b0011: c = a[0] & ~b[0];
> 4'b0111: c = a[1] & ~b[1];
> 4'b1011: c = a[2] & ~b[2];
> 4'b1111: c = a[3] & ~b[3];
> endcase
>
> endmodule
>
> But this resulted in 8 LUTs, 4xMUXF5, 2xMUXF6, and 1xMUXF7. Is there a way to
> write this so it'll fit in 4 LUTs without resorting to instantiating
> the MUXF5/MUXF6 manually?
Article: 76780from what I understand.. you cant infer different bus widths sorry.. Not even Synplify can Simon "Elder Costa" <elder.costa@terra.com.br> wrote in message news:31umvgF3h46qjU1@individual.net... > Hello folks. > > I have implemented the entity bellow by instantciating a dual ported > block RAM with different bus widths (RAMB16_S18_S36 - I am developing > for Virtex II or Spartan 3). Whereas it is relatively simple to do it by > instantiacing the component from Xilinx library, I wonder if there is a > way to code the module so that Xst infers the block RAM. I tried in one > or two ways but it used logic in slices instead of BRAM and it required > a lot of logic for a 1kib RAM. Could somebody give a hint on this? I > looked at Xilinx documentation and couldn't find an example for this > particular problem. > > entity gaintab is > Port ( > -- ports de acesso do processador > i_ProcAddr : in std_logic_vector(9 downto 0); > i_ProcDataIn : in std_logic_vector(15 downto 0); > i_ProcWr : in std_logic; > i_ProcEn : in std_logic; > i_ProcClk : in std_logic; > o_ProcDataOut : out std_logic_vector(15 downto 0); > -- ports de acesso interno (fpga) > i_FpgaAddr : in std_logic_vector(6 downto 0); > i_FpgaClk : in std_logic; > o_FpgaDataOut : out std_logic_vector(31 downto 0) > ); > end gaintab; > > > TIA. > > Elder. >Article: 76781
Colin wrote: > > On a somewhat related subject I have fiddled with setting the > iostandard in VHDL. <snip> but what about a simple net out of > the top level entity with IOB created by synthesis. > See example below Brian -- -- I/O pin attribute example for Xilinx Spartan3 eval kit -- entity ram_test is port ( -- -- default clock osc. -- clk50_in : in std_logic; -- -- 4 pushbuttons, 8 slide switches -- pb : in std_logic_vector(3 downto 0); sw : in std_logic_vector(7 downto 0); -- -- individual leds -- led : out std_logic_vector(7 downto 0); -- -- muxed seven segment LEDs -- digit : out std_logic_vector(3 downto 0); seg_a : out std_logic; seg_b : out std_logic; seg_c : out std_logic; seg_d : out std_logic; seg_e : out std_logic; seg_f : out std_logic; seg_g : out std_logic; seg_dp : out std_logic; -- -- SRAM signals -- -- -- shared control and address -- ram_we_l : out std_logic; ram_oe_l : out std_logic; ram_addr : out std_logic_vector(17 downto 0); -- -- per-bank SRAM signals -- ram_a_dat : inout std_logic_vector(15 downto 0); ram_a_ce_l : out std_logic; ram_a_ub : out std_logic; ram_a_lb : out std_logic; ram_b_dat : inout std_logic_vector(15 downto 0); ram_b_ce_l : out std_logic; ram_b_ub : out std_logic; ram_b_lb : out std_logic ); attribute loc : string ; attribute slew : string ; attribute drive : string ; attribute iostandard : string ; attribute loc of clk50_in : signal is "t9"; attribute iostandard of clk50_in : signal is "LVCMOS33"; attribute loc of pb : signal is "l14,l13,m14,m13"; attribute iostandard of pb : signal is "LVCMOS33"; attribute loc of sw : signal is "k13,k14,j13,j14,h13,h14,g12,f12"; attribute iostandard of sw : signal is "LVCMOS33"; attribute loc of led : signal is "p11,p12,n12,p13,n14,l12,p14,k12"; attribute iostandard of led : signal is "LVCMOS33"; attribute slew of led : signal is "SLOW"; attribute loc of digit : signal is "e13,f14,g14,d14"; attribute iostandard of digit : signal is "LVCMOS33"; attribute slew of digit : signal is "SLOW"; attribute loc of seg_a : signal is "e14"; attribute iostandard of seg_a : signal is "LVCMOS33"; attribute slew of seg_a : signal is "SLOW"; attribute loc of seg_b : signal is "g13"; attribute iostandard of seg_b : signal is "LVCMOS33"; attribute slew of seg_b : signal is "SLOW"; attribute loc of seg_c : signal is "n15"; attribute iostandard of seg_c : signal is "LVCMOS33"; attribute slew of seg_c : signal is "SLOW"; attribute loc of seg_d : signal is "p15"; attribute iostandard of seg_d : signal is "LVCMOS33"; attribute slew of seg_d : signal is "SLOW"; attribute loc of seg_e : signal is "r16"; attribute iostandard of seg_e : signal is "LVCMOS33"; attribute slew of seg_e : signal is "SLOW"; attribute loc of seg_f : signal is "f13"; attribute iostandard of seg_f : signal is "LVCMOS33"; attribute slew of seg_f : signal is "SLOW"; attribute loc of seg_g : signal is "n16"; attribute iostandard of seg_g : signal is "LVCMOS33"; attribute slew of seg_g : signal is "SLOW"; attribute loc of seg_dp : signal is "p16"; attribute iostandard of seg_dp : signal is "LVCMOS33"; attribute slew of seg_dp : signal is "SLOW"; attribute loc of ram_addr : signal is "l3,k5,k3,j3,j4,h4,h3,g5,e4,e3,f4,f3,g4,l4,m3,m4,n3,l5"; attribute iostandard of ram_addr : signal is "LVCMOS33"; attribute slew of ram_addr : signal is "SLOW"; attribute drive of ram_addr : signal is "24"; attribute loc of ram_we_l : signal is "g3"; attribute iostandard of ram_we_l : signal is "LVCMOS33"; attribute slew of ram_we_l : signal is "FAST"; attribute drive of ram_we_l : signal is "24"; attribute loc of ram_oe_l : signal is "k4"; attribute iostandard of ram_oe_l : signal is "LVCMOS33"; attribute slew of ram_oe_l : signal is "SLOW"; attribute drive of ram_oe_l : signal is "12"; attribute loc of ram_a_dat : signal is "r1,p1,l2,j2,h1,f2,p8,d3,b1,c1,c2,r5,t5,r6,t8,n7"; attribute iostandard of ram_a_dat : signal is "LVCMOS33"; attribute slew of ram_a_dat : signal is "SLOW"; attribute drive of ram_a_dat : signal is "6"; attribute loc of ram_a_ce_l : signal is "p7"; attribute iostandard of ram_a_ce_l : signal is "LVCMOS33"; attribute slew of ram_a_ce_l : signal is "SLOW"; attribute drive of ram_a_ce_l : signal is "12"; attribute loc of ram_a_lb : signal is "p6"; attribute iostandard of ram_a_lb : signal is "LVCMOS33"; attribute slew of ram_a_lb : signal is "SLOW"; attribute drive of ram_a_lb : signal is "12"; attribute loc of ram_a_ub : signal is "t4"; attribute iostandard of ram_a_ub : signal is "LVCMOS33"; attribute slew of ram_a_ub : signal is "SLOW"; attribute drive of ram_a_ub : signal is "12"; attribute loc of ram_b_dat : signal is "n1,m1,k2,c3,f5,g1,e2,d2,d1,e1,g2,j1,k1,m2,n2,p2"; attribute iostandard of ram_b_dat : signal is "LVCMOS33"; attribute slew of ram_b_dat : signal is "SLOW"; attribute drive of ram_b_dat : signal is "6"; attribute loc of ram_b_ce_l : signal is "n5"; attribute iostandard of ram_b_ce_l : signal is "LVCMOS33"; attribute slew of ram_b_ce_l : signal is "SLOW"; attribute drive of ram_b_ce_l : signal is "12"; attribute loc of ram_b_lb : signal is "p5"; attribute iostandard of ram_b_lb : signal is "LVCMOS33"; attribute slew of ram_b_lb : signal is "SLOW"; attribute drive of ram_b_lb : signal is "12"; attribute loc of ram_b_ub : signal is "r4"; attribute iostandard of ram_b_ub : signal is "LVCMOS33"; attribute slew of ram_b_ub : signal is "SLOW"; attribute drive of ram_b_ub : signal is "12"; end ram_test;Article: 76782
Hi, I'm working on project of digital encoder '1 from 16' to natural binary code on LPM elements. I'm able to do it in VHDL, AHDL, on gates, 74148 etc. but I didn't find function like lpm_encode in MAX+plus II 10.1, or any other parameterized function from LPM library, that will allow me to do my encoder. There is a lpm_decode function only. Is there any solution? Thanks for any advice Best regardsArticle: 76783
"Chris Ebeling" <christopher.ebeling@xilinx.com> wrote in message news:41BA1E7C.4F6EF452@xilinx.com... > Annti, > > Your correct this can be done. But your coding style isn't exactly conducive :) thanks - well that coding style isnt mine it was from original poster, it did surprise, I have never used that and possible never will. surprising is that it yields to correct synthesis but not using muxF while the other styles will use muxF I think more in low level terms. started 1979 (or even before) with 7400 "things" today trying to use only minimal set ot vhdl/verilog anttiArticle: 76784
On Fri, 10 Dec 2004 17:07:26 -0800, Chris Ebeling wrote:
> Nope,
>
> Quote:
> But this resulted in 8 LUTs, 4xMUXF5, 2xMUXF6, and 1xMUXF7.
>
> This is exactly what you should expect for a 4 bit select vector
> MUXF6 = 8:1, MUXF7 = 16:1.
>
> If you run my example through the tools you can review the results and
> see that each (of the 4 LUTs) is already fully unitized with 4 inputs
> (f, s(0), A#, B#). So you can't get anything more complex, without
> using more logic.
You can fit it in 4 LUTs, if you reorder things a bit.
Feed each of the 4 LUTs with (f[0], f[1], A#, B#), and then select
the output bit with the MUXF5, MUXF6, feeding them with s[0] and s[1]
respectively.
What I originally started with is the following:
module lut_test( a, b, c, f, s );
input [3:0] a, b;
input [1:0] s;
input [1:0] f;
output c;
reg [3:0] lut_out;
reg c;
always @(a or b or f)
case(f)
2'b00: lut_out <= a & b;
2'b01: lut_out <= a | b;
2'b10: lut_out <= a ^ b;
2'b11: lut_out <= a & ~b;
endcase
always @(lut_out or s)
case(s)
2'b00: c = lut_out[0];
2'b01: c = lut_out[1];
2'b10: c = lut_out[2];
2'b11: c = lut_out[3];
endcase
endmodule
Now, if I run that through the tools I get 4 LUTs to calculate
each bit of lut_out[3:0], as I would expect.
However, the 4-1 mux is not implemented using the MUXF5/MUXF6, as I
had hoped, but using another 2xLUT3 + MUXF5. By hard instantiations of
a MUXF5/MUXF6 pair, I can force the desired packing, but I would like
to avoid tricks like that because it makes the code less readable and
harder to port to other devices. Is there any way to achieve that ?
Article: 76785kender wrote: > Hi, I've read that many of you have realized PCI card using FPGAs... > I have to do something similar, but I hope simpler, for my thesis (I'm > an university student): I have to realize a PCI core (but it should > work as a target only device) that should transfer some data that is > collected by the FPGA to an embedded processor, via the PCI bus... > I "just" have to realize the PCI component for the FPGA as all the > other stuff have already been done (and maybe connect the component to > data acquisition logic) and the processor already has its own PCI > controller (that acts as master and arbiter), so my question is: where > should I start from? > > I've read part of the PCI Local Bus Specification but I have some > doubts about the addressing differences.. What might help is to write the testbench first!! Although this sounds odd, what results from this is not only will you have to fully understand the PCI target portion of the specification, it will also you in the planning of the datapath of your PCI target core. It works for me!!Article: 76786
Ben Popoola wrote:
> What might help is to write the testbench first!!
> Although this sounds odd, what results from this is not only will you
> have to fully understand the PCI target portion of the specification, it
> will also you in the planning of the datapath of your PCI target core.
> It works for me!!
I agree. Even commercial cores have free
documentation and an evaluation model and testbench.
For me step one is to make the core model run with
it's own testbench on my simulator.
Step two is to make the trial core play with the rest of
my design in an HDL simulation. What better way to
learn and understand the interface?
However, I realize that some designers prefer a
download and go, trial and error process over
hdl simulation. This doesn't work for me,
but I don't doubt that works for some.
-- Mike Treseler
Article: 76787Stephen Williams wrote: > So is there a way that I'm missing for getting a single software- > selectable output clock with a nearly 50/50 duty cycle ranging > from 20 to 85MHz? On an XC2V3000-4? Peter Alfke did a design were he build a phase accumulator running at a few hundred MHz to generate a square wave with almost arbitrary frequency but a few ns jitter. If you feed the result threw a DCM apparently the jitter is reduced to about 100ps. That should be good enough for your application. Kolja SulimmaArticle: 76788
"Kolja Sulimma" <news@sulimma.de> schrieb im Newsbeitrag news:41bb8bc2$0$16030$9b4e6d93@newsread4.arcor-online.net... > > So is there a way that I'm missing for getting a single software- > > selectable output clock with a nearly 50/50 duty cycle ranging > > from 20 to 85MHz? On an XC2V3000-4? > > Peter Alfke did a design were he build a phase accumulator running at a > few hundred MHz to generate a square wave with almost arbitrary > frequency but a few ns jitter. > If you feed the result threw a DCM apparently the jitter is reduced to > about 100ps. That should be good enough for your application. Are you sure? I thought that the DCM does NOT reduce jitter and furthermore has very tight input jitter reqirements (300ps cycle to cycle, 1ns periodic max.) Its a DCM, not a PLL. Regards FalkArticle: 76789
I resolved by myself. Regards, NaohikoArticle: 76790
Greetings ! I'm looking for a simple RS232 UART16550 receiver for my tiny cyclone board for different baudrates, 8databits, 1stop&startbit and no(!) partity and handshake stuff. I found several free VHDL implementations in the net but compared to what I need they are to complicated and appear like shooting with missiles on birds ;-) The entity might have a simple structure like this: entity receiver is generic( frequency : integer := 10000000; -- e.g. for 10MHz baudrate : integer := 9600 -- e.g. for 9600bps ); port( clk : in std_logic; -- clockspeed is 'frequency' reset : in std_logic; -- resets the receiver receiver : in std_logic; -- input from receive pin from RS232 connector char_avail : out std_logic; -- indicated that a valid char has beed received char : out std_logic_vector(7 downto 0) -- received char, only available for one clock ); end receiver; The 'reciever' values are 'active high'... This structure gives the responsibility for catching received data in time to the user but surely allowes adding a FIFO. Probably this question has been asked about 47283407239 times in this group so please just send me a usefull link or code snippet... Konstantin -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/Article: 76791
"Konstantin Dols" <Konstantin.Dols@rwth-aachen.de> wrote in message news:opsiv94toznxvpac@pc113... > > > Greetings ! > > I'm looking for a simple RS232 UART16550 receiver for my tiny cyclone > board > for different baudrates, 8databits, 1stop&startbit and no(!) partity and > handshake stuff. > > I found several free VHDL implementations in the net but compared to what > I need > they are to complicated and appear like shooting with missiles on birds > ;-) > www.opencores.org (but probably something you have already investigated). The UART "problem" seems to be a pretty common example in various VHDL books. I think Ben Cohen's book has an implementation as well as Navabi's. I can't comment on how or if they work (synthesis). Have you prowled around on the Xilinx web site. A quick search popped up lots of internal links, for example http://www.xilinx.com/bvdocs/appnotes/xapp699.pdf http://www.xilinx.com/bvdocs/appnotes/xapp223.pdf but these may be the "missles" you are refering to. xapp223.pdf does look promising however... If it was me, I'd start with one of the "missles" and start paring it down, removing features. > > > The entity might have a simple structure like this: > > entity receiver is > generic( frequency : integer := 10000000; -- e.g. for 10MHz > baudrate : integer := 9600 -- e.g. for 9600bps > ); > > port( clk : in std_logic; -- clockspeed is 'frequency' > reset : in std_logic; -- resets the receiver > receiver : in std_logic; -- input from receive pin from RS232 connector > > char_avail : out std_logic; -- indicated that a valid char has beed > received > char : out std_logic_vector(7 downto 0) -- received char, only available > for one clock > ); > end receiver; > > The 'reciever' values are 'active high'... > > This structure gives the responsibility for catching received data in time > to the user > but surely allowes adding a FIFO. > > > Probably this question has been asked about 47283407239 times in this > group > so please just send me a usefull link or code snippet... > > > Konstantin > > -- > Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/Article: 76792
Hello all, Will an FPGA PLL lock onto a biphase mark(Manchester ??) encoded signal? I'm trying to build an SPDIF receiver and am wondering if its possible to directly connect the input signal(after analog level adjustment) to an FPGA and read the level at the 90 and 270 degree phases. If frames are continuously being transmitted when the PLL attempts to lock on, how does it know which frequency to use? It seems if all zeros are being transmitted the PLL will lock to half the frequency it should.Article: 76793
Hi all,
Christmas is closing so everybody is making presents. So is Xilinx. I just
got mine! Read the story below:
***********************************************************************
ISE/EDK/ChipScope update to 6.3
In attempt to get our EDK based SoC systems up and running again in EDK 6.3
I ended up creating simplest possible SoC using BSB (because none of working
EDK 6.2 projects worked after update no matter any attempts to get them
working). Attempted to debug in XMD: fatal disaster BRAM can be loaded from
elf, can also look at the disassembly all is ok. Any attempt to trace or
execute simplest program and all goes pasta, not any more possible to view
(or write) even to LMB RAM ! Then I added ChipScope bus analyzer core to OPB
bus. And simplified the test application. Here is the source code:
-----------------------------------------------------------
// Xilinx Christmas Lights application ver 1.0
while (1) {
i++;
WriteToGPOutput(XPAR_LED_7SEGMENT_BASEADDR, i);
}
-----------------------------------------------------------
This is running in MicroBlaze SoC at system frequency 50MHz. Pretty much all
leds should be lit, right? Or?
It looks like (due to Christmas feeling !?) Xilinx tools have decided for me
that my application should be "Christmas Lights" - because that how it
works! The LEDS are blinking in fancy true random fashion at "human" blink
rate, ie very slowly. The visual effects are pretty cool, really!
When looking in ChipScope (OPB bus analyzer) I see writes to the GPIO port:
0x00800000, 0x01000000,0x02000000,0xFFFFFFE,0xFFFFFFC... Those are 5 example
sequential writes to GPIO port (from the above program!), notice that
between the GPIO writes there is always more than 512 OPB clocks of no OPB
bus activity.
And yes, I did UNINSTALL ALL ISE/EDK/ChipScope before update, then installed
all the new versions plus service packs, etc..
***********************************************************************
Antti
Article: 76794I are having truoble with quartus comiling my designs. I did a design in schematic and it worked correctly until I inserted a AHDL uart at witch time the uart was unstable every thing else worked fine. My supplier advised me that I shouldn't use the schematic as it doesn't compile properly and things can work one time and then do a small change and they do not the next. So I wrote it all out with his help in AHDL. Things eventually started to fall into place excpt that a have a very unstable design. sure the uart worked well but every time I compile it with a slight change the something else does not work properly. Conseqently I have no faith in AHDL file at all. The schematic still works fine without the uart. Has anybody else come accross this and do they have any solutions for the problem. Is it a common consencuse that schematic is not the method that should be used and AHDL or VHDl is the only reliable way to program these? I are using quartus 4.2 sp2 WE and flex6000 device. DanielArticle: 76795
Hi Daniel, It's quite unlikely that this is a problem with the AHDL synthesis support in Quartus. That support is very extensively tested, and used by thousands of users, so it's much, much more likely that there is a problem with your UART design than a problem with the AHDL support in Quartus. Usually "unstable" hardware that works sometimes and not others, or works on one compile and not others is due to race conditions or missed timing constraints in your design. Have you followed proper asynchronous design practice for all asynchronous transfers in your design? If you search this newsgroup, you'll find some pointers to good documents giving tutorials on asynchronous design. Have you set timing constraints on all your synchronous transfers, and checked the Quartus timing report to be sure they were all met? Are you using a disciplined reset scheme, or performing a recovery & removal timing analysis (see Quartus 4.2 help) to check your design will reset cleanly? Vaughn Altera "Daniel" <daniel.tasc@xtra.co.nz> wrote in message news:4953ed5f.0412121228.4c95b803@posting.google.com... > I are having truoble with quartus comiling my designs. I did a design > in schematic and it worked correctly until I inserted a AHDL uart at > witch time the uart was unstable every thing else worked fine. My > supplier advised me that I shouldn't use the schematic as it doesn't > compile properly and things can work one time and then do a small > change and they do not the next. So I wrote it all out with his help > in AHDL. Things eventually started to fall into place excpt that a > have a very unstable design. sure the uart worked well but every time > I compile it with a slight change the something else does not work > properly. Conseqently I have no faith in AHDL file at all. The > schematic still works fine without the uart. Has anybody else come > accross this and do they have any solutions for the problem. Is it a > common consencuse that schematic is not the method that should be used > and AHDL or VHDl is the only reliable way to program these? I are > using quartus 4.2 sp2 WE and flex6000 device. > > DanielArticle: 76796
On Tue, 7 Dec 2004, Marc Randolph wrote: > ... In short, I think we're doing a pretty good > job of exploring the limits on that chip, and the MGT keeps running > error free, even at industrial temperatures (junction of 100C). > > Having used them, here are my suggestions: > > 1. Follow the Xilnix guidelines for power filtering on the MGT and > vccaux. > 2. Use a low jitter clock reference for the MGT. No PLL or DLL > sources. A cheap crystal osc will do just fine. > 3. Use the BREFCLK pin for the MGT if possible. > 4. Use the flip-chip package if possible. Not a requirement, but > it'll just make signals, ground, and power just that much better. > What is your feeling about using RocketIO over 5 meters of copper cable ? Assuming we follow your suggestions and that we get good cables and connectors, what is the data rate that we could reach reliably ? Thanks, Tullio GrassiArticle: 76797
Hello,
I wanted to know how you instruct MAP to place an LUT and a MUXF5
into the same slice. Looking at the V2 Datasheet, it seems to be an
allowed combination. However, I get a MAP error stating that the LUT and
MUXF5 cannot share the same slice. I'm specifiying the constraints
within the VHDL (again, inspired by Ray Andraka).
Thanks!
-Jim
Article: 76798Tullio Grassi wrote: > On Tue, 7 Dec 2004, Marc Randolph wrote: > > >>... In short, I think we're doing a pretty good >>job of exploring the limits on that chip, and the MGT keeps running >>error free, even at industrial temperatures (junction of 100C). >> >>Having used them, here are my suggestions: >> >>1. Follow the Xilnix guidelines for power filtering on the MGT and >>vccaux. >>2. Use a low jitter clock reference for the MGT. No PLL or DLL >>sources. A cheap crystal osc will do just fine. >>3. Use the BREFCLK pin for the MGT if possible. >>4. Use the flip-chip package if possible. Not a requirement, but >>it'll just make signals, ground, and power just that much better. >> > > > > What is your feeling about using RocketIO over 5 meters of copper cable ? > Assuming we follow your suggestions and that we get good cables and > connectors, what is the data rate that we could reach reliably ? > > Thanks, > > Tullio Grassi What kind of copper cable? What sort of drive will you be doing? Any preemphasis? This is a perfect thing to try in simulation. Set up your drivers, receivers, and cable, then look at some eyes. Don't forget the connectors and the traces on the PC boards.Article: 76799
Adam wrote: > Hello all, > > Will an FPGA PLL lock onto a biphase mark(Manchester ??) encoded signal? > I'm trying to build an SPDIF receiver and am wondering if its possible to > directly connect the input signal(after analog level adjustment) to an FPGA > and read the level at the 90 and 270 degree phases. If frames are > continuously being transmitted when the PLL attempts to lock on, how does it > know which frequency to use? It seems if all zeros are being transmitted > the PLL will lock to half the frequency it should. > > Probably not for a Xilinx Virtex II, Spartan III or Virtex II Pro, the FPGA specs state that the DCM inputs must have < 1ns period jitter, outside which they will lose lock. A true-PLL design may be more forgiving, though. -Jim
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