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
Well, we could always start a user group on google. However, I would predict within the hour there would be a Xilinx FAE trying to sell us on some new product. Perhaps we could call it something tricky like KDE?Article: 97051
Hi, me_2003@walla.co.il wrote: > I have another question regarding the PLB-OPB, the PPC405 reference > guide says that the PLB should be used for fast bus transactions and > that the OPB is to be used for slower peripherals (GPIOs/UART etc.). > My question is as follows - If I'm using a PLB-OPB bridge the data > from/to the OPB will still go trough the PLB bus so how come it is says > the the OPB usage takes some load of the PLB bus ? > Thanks, Mordehay. In this case, "load" means capacitive load or fanout. By having fewer peripherals directly connected to the PLB, you may be able to clock the PLB at a higher frequency, thus increasing performance. Best regards EnnoArticle: 97052
David Brown <david@westcontrol.removethisbit.com> wrote: >nospam wrote: >> Luc <bnl_rsm.lscc@telenet.be> wrote: >> >>> May I remind you that that the leadfree, RoHS and Green stuff started >>> in Japan, not in Europe. >> >> You may and I have heard the claim before, but when I look I find no >> evidence that is it true. >> > >As far as I understand it, Japan has had a number of restrictions such >as lead-free (or at least, reduced lead), for many years. However, the >restrictions are not as strict as the new EU directives. I couldn't >give you any more details or pointers, however, nor can I remember where >I read about it. From my limited browsing on the subject Japan has no 'lead free' legislation. Early on some Japanese companies went lead free on certain products so they could stick green labels on them and claim a marketing advantage. When forthcoming Euro legislation was announced the Japanese (being Japanese) recognised the potential of gaining an advantage over their competitors by going lead free faster and better and that is what they have been doing. Euro legislation was the driving force behind Japanese lead free production but once started the green label marketing aspect became more important making lead free production for domestic markets more or less mandatory.Article: 97053
Hal Murray wrote:>
> Is counting IO pins, CLBs, BRAMs or ... top or bottom?
Not trying to get into religious wars...
I think it is top level.
I start with a basic outline what I want to achieve ("if you don't know
where you want to go, every way is a right one"), then check up on
required resources, like clocks, pins, RAM etc.
Then go to the bottom and crack the toughest nut, for it will most
likely determine the fate of the whole design...
The beauty with programmable logic is that we can design the pc-board
while a large part of the design is still unfinished. Of course, we all
know (and love) that.
Peter Alfke
Article: 97054KDE is fine with me:), however before starting any new group we should probably make sure there is some substantial interest/support for this... I personally am in a permanent board level design cycle which forces me to switch from one tool/activity to another every 2-3 months... Right now I am in my FPGA phase, but I might be out of it in a couple of months until next time... So, unfortunately I can't be relied upon in organizing and maintaining this kind of thing... /Mikhail "Chris Gammell" <Chris.Gammell@gmail.com> wrote in message news:1140021323.752139.284100@o13g2000cwo.googlegroups.com... > Well, we could always start a user group on google. However, I would > predict within the hour there would be a Xilinx FAE trying to sell us > on some new product. Perhaps we could call it something tricky like KDE? >Article: 97055
Chris Gammell wrote: > Well, we could always start a user group on google. However, I would > predict within the hour there would be a Xilinx FAE trying to sell us > on some new product. Perhaps we could call it something tricky like KDE? Chris, do you have any proof for that (insulting) statement? I think this ng tries to be informative and helpful, and keeps commercials to a bare minimum. If you advocate the absence of Xilinx and Altera voices, I hope you are alone. Peter AlfkeArticle: 97056
"MM" <mbmsv@yahoo.com> wrote in message news:45h1h2F6cgj6U1@individual.net... > Chris, > > Unfortunately I can't help you, I am just another confused EDK user. I was > wondering if there is a more specialized user group/mailing list that > would > be primarily concentranting on EDK? The one on Xilinx site doesn't look > too > alive... > > > /Mikhail > Please don't leave us! :-) Seriously, it'd be helpful if you guys kept on using CAF. Those of us who are occasional users of EDK are also interested in these posts, and it'd be useful to keep this in the same group, IMO. Why not just put [EDK] in your subject line and use your news reader to separate out relevant posts? Cheers, Syms.Article: 97057
>But we must all realize: >those designs were created between 1968 and 1971, i.e. more than 35 >years ago 7400 a good way to learn digital electronics, there are many CHEAP books available on the subject. This is for a hobby, not a job. I learned with these chips, looking at old schematics and books. Can anyone reccomend a text that will be good for transisiton between 7400 and VHDL ? RichArticle: 97058
1> This is a document error. The bram_block takes in the address bus from the standardized bus (PLB, OPB, LMB, etc), and internally slices off the address lines. It's easy to recognize the usage from the HDL description. Take a look at <proj>/hdl/elaborate/<inst>_elaborate_v1_00_a/hdl/vhdl/<inst>_elaborate.vhd If you want to access one side externally, take a look at http://www.xilinx.com/techdocs/20353.htm 2> You'll have to accomplish this using multiple bram_blocks. The first bram_block is 64kB, the 2nd is 32kB, and the 3rd is 4kB. In this case, however, you face an issue with the initialization of the bitfile. Take a look at this AR http://www.xilinx.com/techdocs/19991.htm Or, you can write a linker script as suggested here to workaround the data2mem issue. http://www.xilinx.com/techdocs/16536.htm MM wrote: > Hi all, > > I have 2 questions on different ways of using BRAM in EDK: > > 1. I have created a PPC system with DSOCM_BRAM and I am trying to make one > side of it external for some external logic to access. The block is only 32 > KB, but EDK would not allow me to set the address bus width (C_PORT_AWIDTH) > to below 32 bit... This is confusing as according to the BRAM Block > datasheet C_PORT_AWIDTH cannot be bigger than 17! So, should I just ignore > extra pins or what? > > 2. In the same system I have PLB_BRAM, which I want to be let's say 100 KB. > However, the EDK seems to only accept a power of 2 size, i.e. either 64 KB > or 128 KB. I was hoping that I could configure the controller for 128 KB > range but physically assign a smaller block of memory to it. Is this > possible? > > > Thanks, > /Mikhail > >Article: 97059
If the weblinks, just go to the xilinx web site and type in the AR # in the search field. Paulo Dutra wrote: > 1> > This is a document error. The bram_block takes in the address bus from > the standardized bus (PLB, OPB, LMB, etc), and internally slices off the > address lines. It's easy to recognize the usage from the HDL > description. Take a look at > <proj>/hdl/elaborate/<inst>_elaborate_v1_00_a/hdl/vhdl/<inst>_elaborate.vhd > If you want to access one side externally, take a look at > http://www.xilinx.com/techdocs/20353.htm > > 2> > You'll have to accomplish this using multiple bram_blocks. > The first bram_block is 64kB, the 2nd is 32kB, and the 3rd is 4kB. > In this case, however, you face an issue with the initialization of the > bitfile. Take a look at this AR > http://www.xilinx.com/techdocs/19991.htm > Or, you can write a linker script as suggested here to workaround the > data2mem issue. > http://www.xilinx.com/techdocs/16536.htm > > MM wrote: >> Hi all, >> >> I have 2 questions on different ways of using BRAM in EDK: >> >> 1. I have created a PPC system with DSOCM_BRAM and I am trying to make >> one >> side of it external for some external logic to access. The block is >> only 32 >> KB, but EDK would not allow me to set the address bus width >> (C_PORT_AWIDTH) >> to below 32 bit... This is confusing as according to the BRAM Block >> datasheet C_PORT_AWIDTH cannot be bigger than 17! So, should I just >> ignore >> extra pins or what? >> >> 2. In the same system I have PLB_BRAM, which I want to be let's say >> 100 KB. >> However, the EDK seems to only accept a power of 2 size, i.e. either >> 64 KB >> or 128 KB. I was hoping that I could configure the controller for 128 KB >> range but physically assign a smaller block of memory to it. Is this >> possible? >> >> >> Thanks, >> /Mikhail >> >>Article: 97060
Hi, California is adopting the Eu RoHS rules in January 2007. So it will probably affect all American electronics companies soon. Some of the exceptions are a bit annoying - e.g. disk drives are exempt till 2009! Server class computers! I am finding it difficult to obtain components that meet the rules - in many cases distributors such as Digikey do not stock the lead-free parts even if available. I have also had to spin designs since the component manufacturer have decided not to make all of their packages lead-free - choosing to obsolete the device in that package!. kevinArticle: 97061
Slurp wrote: > Before any of you VHDL guys start shouting - ahhh but its much quicker using > a description language I will say that most of my designs work first time - > and I have always got there much faster than any guy writting high level in > any language - and with a fully documented, easily modified design. > > Designing at schematic level does NOT necessarily mean gate/counter level > either, a single component may easily be a complex processing function. To be honest, I don't use HDLs because they are "faster" than schematics. I use them because I can create comprehensive test benches to simulate and verify my design before it's committed to the PCB. My test benches include models of the other devices on the board -- memories, processors, whatever. I find that debugging the real hardware is a lot easier when I've simulated the design. And if I do find a bug in the hardware, I recreate the bug in the simulation, which simplifies fixing the bug. A bonus is that with an HDL, I can take advantage of source-code control tools such as subversion. What changed between this version and that? Let's check the log. Oh, yeah, that; now let's diff the old code and the new code to see exactly how this changed. I suppose another bonus is that you're not hung out to dry when your FPGA vendor decides to change the schematic formats. -aArticle: 97062
Thanks a lot Paulo! "Paulo Dutra" <paulo.dutra@NOSPAM.com> wrote in message news:43F377A3.7030006@NOSPAM.com... > 1> > This is a document error. The bram_block takes in the address bus from > the standardized bus (PLB, OPB, LMB, etc), and internally slices off the > address lines. It's easy to recognize the usage from the HDL > description. Take a look at > <proj>/hdl/elaborate/<inst>_elaborate_v1_00_a/hdl/vhdl/<inst>_elaborate.vhd > If you want to access one side externally, take a look at > http://www.xilinx.com/techdocs/20353.htm Yeah, I actually found it myself, however I am still having some difficulties, which I am not sure at the moment whether they are related to BRAM. In any case I understand that the bus side is standardized, but why would the second side be similarly constrained ? BTW, I don't quite understand what happens to the second side by default? Is it simply hanging? /MikhailArticle: 97063
1> I have written demos where microblaze accesses the ILMB without IOPB. Where did you see this listed? Also, I have a demo with IOB without ILMB. MB just needs to have memory at start address 0x0 either on IOPB or ILMB. The ILMB is just faster since only 1 master is allowed thus no bus arbitration therefore preferred. me_2003@walla.co.il wrote: > Hi all, > I have two questions regarding the OPB usage. > 1) why is it the microblaze connects to the IOPB port to the OPB bus > when running from internal memory (BRAM) ? the program runs only from > the ILMB isn't it? > 2) PLB-OPB bridge , the PPC405 reference guide says that the PLB should > be used for fast bus transactions and that the OPB is to be used for > slower peripherals (GPIOs/UART etc.). My question is as follows - If > I'm using a PLB-OPB bridge the data > from/to the OPB will still go trough the PLB bus so how come it is says > > the the OPB usage takes some load of the PLB bus ? > Thanks, Mordehay. >Article: 97064
I believe this is just simplicity in the way the automation tools wire up the bram_cntlr to the bram_block. Allowing the bram_block to perform the address slicing internally. The unused address lines are left hanging allowing the map/par tools to trim away the hanging logic. MM wrote: > Thanks a lot Paulo! > > > "Paulo Dutra" <paulo.dutra@NOSPAM.com> wrote in message > news:43F377A3.7030006@NOSPAM.com... >> 1> >> This is a document error. The bram_block takes in the address bus from >> the standardized bus (PLB, OPB, LMB, etc), and internally slices off the >> address lines. It's easy to recognize the usage from the HDL >> description. Take a look at >> > <proj>/hdl/elaborate/<inst>_elaborate_v1_00_a/hdl/vhdl/<inst>_elaborate.vhd >> If you want to access one side externally, take a look at >> http://www.xilinx.com/techdocs/20353.htm > > Yeah, I actually found it myself, however I am still having some > difficulties, which I am not sure at the moment whether they are related to > BRAM. In any case I understand that the bus side is standardized, but why > would the second side be similarly constrained ? BTW, I don't quite > understand what happens to the second side by default? Is it simply hanging? > > > > /Mikhail > >Article: 97065
mattdykes wrote: > Thanks, Dave. I'm a dumb arse. I'm finishing up a project for a > co-worker and didn't notice he was using every library know to man. > > Note to self: > Don't include ieee.std_logic_signed.all AND > ieee.std_logic_unsigned.all. What had me perplexed was that I have a project with lots of glue logic and some simple state machines, and I was doing address compares both concurrently and in a process. I only used the IEEE.std_logic_1164 library. But your original code and my code are basically the same (i.e. adrs = "0010"). But, in my first reply, the only way I could get the test code to compile was to use "numeric_std" and the "std_match" function. So, I'm puzzled - have I overlooked something, or is there a subtle VHDL feature that I haven't learned yet? (gentle responses, please! ;) -Dave PollumArticle: 97066
Hi! I'm unsuccessfully tried to follow this instructions given by http://www.altera.com/literature/ds/ds_stratix_dsp_bd_pro.pdf to load a Non-Volatile Configuration on an Altera Stratix EP1S80 DSP Development Board. I have a lead about where the problem might be. According to the instructions, the seven-segment display should read 00 when the "bootloader" for the non-volatile memory is running. The seven-segment display reads 33 instead leading me to think that I have the wrong on-board bootloader. If it is the case, is there anybody aware of where I could find a configuration file (*.sof) doing the job of the non-volatile bootloader? ThanksArticle: 97067
Antti <Antti.Lukats@xilant.com> wrote: > Atmel > ===== > AVR32 Architecture was launched, they had a > gpraphical demonstration with real AVR32 > silicon chip, well it was marked with code > name "Morgan" and there was no actual info > about any AVR32 'orderable parts' only benchmark > comparisons that seemed to prove that AVR32 ISA > beats ARM at 50% on all accounts. > STK525 starterkit (with AT90USB1286) was on display > priced 200EUR is immediatly available. > AT90USB1287 - real nice chip is also available > that is distributors must accept orders as > order entry from Atmel is open - so if your > disti says AT90SUB1287 is not orderable then > the disti has not up-to-date info. > USBKEY Demo board costs 30USD and is based > on AT90SUB1287 I did see it working at the > booth - this board is not immediatly avaiable > as there are 20 of them manufactured as of > today (2 of them being at embedded) but it > should be orderable and should be shipping > shortly as well. I was in Nuernberg today. Some more remarks: Atmel: The AT91SAM9260/1 look nice: Arm9, SDRAM interface, lots of peripherie (EMAC on 9260), small target volume pricing and the 9260 with QFP208 package still usefull for prototyping. Availability: "Soon" according to the people at the Atmel boot. Talking to some distributor, I mentioned my quote "Atmel has a long history of early announcements" and I was somehow confirmed in this opinion by the remark that Atmel anounces the chip, waits for some big design wins and then only really starts to produce the chip with availability for small customers. Philips: The LPC3180 is another ARM 9 competitor. No availablity yet neither and only in a prototyp prohibiting FPBGA320. Probably other variants will come. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 97068
This is a multi-part message in MIME format.
------=_NextPart_000_0016_01C6325B.C92B2AE0
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable
The backannotate command is useful if you want to do one of the =
following:
1. If you do not have complete Pin Assignments (i.e. not speecified the =
location of all your pins) and you want to use the ones that the Quartus =
compiler has generated during fitting, then you should backannotate your =
Pin and Device Assignments.
2. If your design is very close to complete, has critical timing paths =
which need to be preserved and you plan on making very minor tweaks =
only, use the backannotate Pin, Cell and Device Assignments. Use the =
demote cells to AB or else you will overconstrain the fitter. If your =
tweaks invalidate instance names created during the prior compile you =
will get assignments that wil be ignored by the compiler.
3. Finally if your design is complete and you want to preserve routing =
you may want to use backannotate Pin, Cell, Routing and Device =
Assignments. Use this only if your design is complete. If you plan on =
changing your logic remember to remove the cell and routing assignments =
using the Assignment Editor, using the Category Locations. Do not remove =
the pin assignments during this step, or else you will have to enterthem =
again.
We recommend that customers mainly use Options 1 and 2.
Hope this helps
Subroto Datta
Altera Corp.
"Sophie Liu" <mailwz@263.net> wrote in message =
news:dsumss$net$1@news.cn99.com...
Hi, Dears:
I am using QuartusII now. I am not clear to back-annotate. What is =
back_annotate? and what's the use of back-annotate?=20
Thank you!
Jude
------=_NextPart_000_0016_01C6325B.C92B2AE0
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>The backannotate command is useful if =
you want to=20
do one of the following:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>1. If you do not have complete Pin =
Assignments=20
(i.e. not speecified the location of all your pins) and you want to use =
the ones=20
that the Quartus compiler has generated during fitting, then you should=20
backannotate your Pin and Device Assignments.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>2. If your design is very close to =
complete, has=20
critical timing paths which need to be preserved and you plan on=20
making very minor tweaks only, use the backannotate Pin, =
Cell and=20
Device Assignments. Use the demote cells to AB or else you will =
overconstrain=20
the fitter. If your tweaks invalidate instance names created during the =
prior=20
compile you will get assignments that wil be ignored by the=20
compiler.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>3. Finally if your design is complete =
and you want=20
to preserve routing you may want to use backannotate Pin, Cell, Routing =
and=20
Device Assignments. Use this only if your design is complete. If you =
plan on=20
changing your logic remember to remove the cell and routing assignments =
using=20
the Assignment Editor, using the Category Locations. Do not remove the =
pin=20
assignments during this step, or else you will have to enterthem=20
again.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>We recommend that customers mainly use =
Options 1=20
and 2.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Hope this helps</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subroto Datta</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Altera Corp.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Sophie Liu" <<A =
href=3D"mailto:mailwz@263.net">mailwz@263.net</A>>=20
wrote in message <A=20
=
href=3D"news:dsumss$net$1@news.cn99.com">news:dsumss$net$1@news.cn99.com<=
/A>...</DIV>
<DIV><FONT face=3D=CB=CE=CC=E5 size=3D2>
<DIV><FONT face=3D=CB=CE=CC=E5 size=3D2>Hi, Dears:</FONT></DIV>
<DIV><FONT face=3D=CB=CE=CC=E5 size=3D2> I am =
using QuartusII now. I=20
am not clear to back-annotate. What is back_annotate? and what's the =
use of=20
back-annotate? </FONT></DIV>
<DIV><FONT face=3D=CB=CE=CC=E5 size=3D2>Thank you!</FONT></DIV>
<DIV><FONT face=3D=CB=CE=CC=E5 size=3D2></FONT> </DIV>
<DIV><FONT face=3D=CB=CE=CC=E5=20
size=3D2>Jude</FONT></DIV></FONT></DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0016_01C6325B.C92B2AE0--
Article: 97069thanksArticle: 97070
Can i attach an interrupt to FSL perpherial under system generator? if so, how can i do?Article: 97071
Following up on John Providenza's question about the DIFF_OUT
buffer feature, I've put together a small example which builds a
complementary clock input buffer out of two normal IBUFGDS's.
Also for reference, I've copied my original notes about this handy
feature of the V2 & S3 families.
Brian
<from original post>
All the V2-ish differential input buffers have a complementary output
available, that can be used to create a 180 degree clock without
needing a DCM.
These can also be used just to invert a differential input without
needing any other logic (or board cuts & jumps).
Look at the DIFFS component in fpga_editor to see what's going on;
besides the normal 'phantom' route from the DIFFS to the DIFFM,
there's also a route from the DIFFM to a differential receiver in the
DIFFS that outputs the complement signal.
I first spotted these when they showed up in early versions of
XAPP622 as a hard macro.
Support & tool bugs for these have varied version to version,
see Answer Record 21958 for recent problems.
I've banged into various other problems in using them over the years;
if I get a chance this weekend, I'll try to dig up some old webcase
code showing how to create one out of two normal IBUF{G}DS's as
a work around.
These can be used on regular IOB inputs as well as global clock
inputs, but you've generally needed to LOC the global input buffer
and bufg's to allowed sites to get this to work.
search for
ibufgds_diff_out
ibufds_diff_out
<end original post>
<diff_out_test.vhd>
--
--
-- diff_out buffer example
--
-- shows how to create complementary internal clocks using
-- IBUF{G}DS's with neither a DCM nor local inversion required
--
-- forwards a global clock input to output, output/2
--
-- substitutes two ibuf{g}ds's for ibuf{g}ds_diff_out component;
-- various tool revs have choked when using attributes on those
--
-- intended for V2-ish family members
--
-- !!! example LOC constraints specific to XC3S200-FG256 !!!
--
-- COMPLETELY UNTESTED; SYNTHESIZED WITH 6.3 & EXAMINED IN FPGA_EDITOR
--
-- Input Clocking:
-- this example doesn't use the resulting clock for DDR inputs,
-- but best (or at least easier to analyze) DDR input timing may
-- result when using CLB registers rather than DDR IOB input regs
--
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
library unisim;
use unisim.vcomponents.all;
entity diff_out_test is
port
(
global_clk_in_p : in std_logic;
global_clk_in_n : in std_logic;
gclk_out_p : out std_logic;
gclk_out_n : out std_logic;
gclk_div2_p : out std_logic;
gclk_div2_n : out std_logic
);
end diff_out_test;
architecture arch1 of diff_out_test is
--
-- signals
--
signal gclk_iob_p : std_logic;
signal gclk_iob_n : std_logic;
signal gclk : std_logic;
signal gclk_p : std_logic;
signal gclk_n : std_logic;
signal gclk_out : std_logic;
signal gclk_div2 : std_logic;
signal g_toggle : std_logic;
signal g_toggle_not : std_logic;
--
-- LOC the components
--
attribute LOC : string;
--
-- see Answer Record 17697 for script to find local clock sites
-- (complementary clocks are trickier with local routing resources)
--
--
-- inputs have an IBUFDS comp in both DIFFM and DIFFS pin sites
-- to create the diff_out buffer variant
--
attribute LOC of GC1P : label is "D9";
attribute LOC of GC1N : label is "C9";
--
-- outputs need to LOC one OBUFDS to the P pin site
--
attribute LOC of FGC1 : label is "E10";
attribute LOC of FGC2 : label is "C12";
--
-- Note : to use one BUFG for IOB DDR logic clocking,
-- and another for internal logic clocking, intentionally
-- LOC the BUFG's to the sites having the shared routing
-- resources to the IBUFGDS ( may produce spurious ISE warning )
--
-- To locate the shared routing resources, see:
-- Answer Record 19947 for S3
-- Answer Record 11756 for V2
--
attribute LOC of GCLK_BUFGMUX_LOGIC : label is "BUFGMUX4";
attribute LOC of GCLK_BUFGMUX_P : label is "BUFGMUX5";
attribute LOC of GCLK_BUFGMUX_N : label is "BUFGMUX6";
begin
--
-- global clock input
-- two IBUFDS's with input nets swapped
-- in place of IBUFGDS_DIFF_OUT
--
GC1P : IBUFDS_LVDS_25
port map
(
I => global_clk_in_p,
IB => global_clk_in_n,
O => gclk_iob_p
);
GC1N : IBUFDS_LVDS_25
port map
(
I => global_clk_in_n,
IB => global_clk_in_p,
O => gclk_iob_n
);
--
-- note that the use of shared routing resources to two
-- BUFGMUX's from the same internal clock source requires
-- both LOCs and manual selection of the proper I0/I1 input
-- ( see comments near LOCs above )
--
GCLK_BUFGMUX_LOGIC : BUFGMUX
port map
(
S => '1',
I0 => open,
I1 => gclk_iob_p,
O => gclk
);
GCLK_BUFGMUX_P : BUFGMUX
port map
(
S => '0',
I0 => gclk_iob_p,
I1 => open,
O => gclk_p
);
GCLK_BUFGMUX_N : BUFGMUX
port map
(
S => '0',
I0 => gclk_iob_n,
I1 => open,
O => gclk_n
);
--
-- clock divider
--
gdiv2 : fd
port map
(
C => gclk,
D => g_toggle_not,
Q => g_toggle
);
g_toggle_not <= NOT g_toggle;
--
-- DDR output flops
--
GCLK_FWD : FDDRRSE
port map
(
Q => gclk_out,
C0 => gclk_p,
C1 => gclk_n,
CE => '1',
R => '0',
S => '0',
D0 => '1',
D1 => '0'
);
GCLK_DIV2_FWD : FDDRRSE
port map
(
Q => gclk_div2,
C0 => gclk_p,
C1 => gclk_n,
CE => '1',
R => '0',
S => '0',
D0 => g_toggle,
D1 => g_toggle
);
--
-- Output buffers
--
FGC1 : OBUFDS_LVDS_25
port map
(
I => gclk_out,
O => gclk_out_p,
OB => gclk_out_n
);
FGC2 : OBUFDS_LVDS_25
port map
(
I => gclk_div2,
O => gclk_div2_p,
OB => gclk_div2_n
);
end arch1;
Article: 97072can i change the default parameters generated by system generator? for example, changing the FSL FIFO's depth from 16 to 22Article: 97073
Antti wrote: > > the problems with download are not so big issue if the download works > at the end, but not fixing the bugs sure is > I'm just using 8.x for simple test cases at the moment. To actually get any work done, I'm using 6.3 at home, 7.x at work. BTW, thanks for your Embedded World notes: > >Both my youngest have now a ass-sledge with Silica logo > Ass-sledges, along with sharp pointy sticks, can also be quite handy for dealing with buggy FPGA vendors :) BrianArticle: 97074
Can someone please explain to me what the 1QN and 2QN formats are as used in the input and outputs of the Xilinx CORDIC IP? Especially for the case of polar to rectangular conversion aka Vector Rotation mode. And how do I convert between them and two's complement format ? Thank you for any insights. ML
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