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
In article <3cacff43@news.starhub.net.sg>, Kelvin Xu Qijun <qijun@okigrp.com.sg> wrote: >Nicholas, pls stop laugh since they have made it possible that you stay on >your job for a while... >I feel the laziness of CAD companies has saved many jobs in IC design >area...:-) Hehehehhe. I'm an academic, so well, I find it entertaining, not a guarentee of employment. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 41701
"JB" <jbonill1@optonline.net> wrote in message
news:E30r8.139983$u77.31687100@news02.optonline.net...
> I am new come in the FPGA business.
>
> I guess that to implement a monostable multivibrator using a Xilinx FPGA
> should be pretty common.
>
> Maybe somebody provide me with a hint or an example?
>
> Thanks
Hi,
Yes, to my mind the most basic element of clocked logic but in FPGAs
you use a clock rather than an RC timer. Below is some code to play
with that illustrates this. (ignore the fact its called a UART which
it is not of course). The comments in the testbench give the best
clues as to whats going on.
I've run this code on modelsim.
Regards
Phil
-- *******************************************************************
-- Purpose: Top level
-- *******************************************************************
library ieee;
use ieee.STD_LOGIC_1164.all;
use ieee.STD_LOGIC_ARITH.all;
use ieee.STD_LOGIC_MISC.all;
use ieee.STD_LOGIC_UNSIGNED.all;
entity uart is
port (
clock : in STD_LOGIC; -- Master clock
write_en : in std_logic;
output : out STD_LOGIC --
);
end uart;
architecture behavior of uart is
signal we_delay1 : std_logic;
signal we_delay2 : std_logic;
signal we_delay3 : std_logic;
signal we_delay4 : std_logic;
signal we_delay5: std_logic;
begin
--what are we attempting here ? Well to delay a write enable pulse so it
frames the
--rising edge of a write clock pulse.
process(clock) begin
if clock'event and clock='0' then
we_delay1 <= write_en; --set up a train of waveforms delayed by 1
clock
we_delay2 <= we_delay1;
we_delay3 <= we_delay2;
we_delay4 <= we_delay3;
we_delay5 <= we_delay4;
--craft the output required
output <= we_delay1 and not we_delay2; -- rising on delay1 and
falling on
-- other outputs can be crafted with other logic
-- delay2
end if;
end process;
end
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-- *******************************************************************
-- Purpose: UART test bench to test code snippets
-- *******************************************************************
library ieee;
use ieee.STD_LOGIC_1164.all;
use ieee.STD_LOGIC_ARITH.all;
use ieee.STD_LOGIC_MISC.all;
use ieee.STD_LOGIC_UNSIGNED.all;
entity testbench is
end ;
architecture behavior of testbench is
component uart
port (
clock : in STD_LOGIC; -- Master clock
write_en : in std_logic;
output : out STD_LOGIC --
);
end component;
signal regionoftest : std_logic;
signal clock : STD_LOGIC;
signal write_en : std_logic;
signal output : STD_LOGIC;
signal i : INTEGER := 0;
begin
-- Instantiate UART top level module
uart_test: uart
port map (
clock => clock ,
write_en => write_en ,
output => output );
-- Generate Clock - 20 ns period
process
begin
loop
clock <= '1';
wait for 10 ns ;
clock <= not(clock);
wait for 10 ns ;
end loop;
end process;
-- Main test program
process
----------------------------------------------------------------
--**************main test sequence******************************
begin
--initialise
write_en <= '0';
regionoftest <= '1';
wait for 100 ns;
--wip
--long write enable
write_en <= '1';
wait for 102 ns;
write_en <= '0';
--short write enable
wait for 47 ns ;
write_en <= '1';
wait for 30 ns ;
write_en <= '0';
wait for 100 ns;
--too short - less than clock period (glitch suppression) but still
catches a -ve edge.
write_en <= '1';
wait for 15 ns ;
write_en <= '0';
wait for 100 ns;
--too short - less than clock high and not capturing an edge
write_en <= '1';
wait for 5 ns ;
write_en <= '0';
--too short - less than clock high but still capturing an edge so output
present
wait for 108 ns;
write_en <= '1';
wait for 5 ns ;
write_en <= '0';
wait;
end process;
--**************end of main test sequence***********************
----------------------------------------------------------------
end;
xxxxxxxxxxxxxxxx end of message xxxxxxxxxxxxxxxxxxxxxxxxxxxx
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Article: 41702"Christopher Saunter" <Christopher.Saunter@durham.ac.uk> wrote in message news:a8h9ff$qhq$1@sirius.dur.ac.uk... > Greetigns All, > > I have always found it more natural to work with schematics than an HDL > (although learnign vhdl is proving very usefull in some areas...) > > I have used the Aldec schematic capture program from Xilinx Foundation 3/4 > and ECS from Webpack. > > Thus far, I am somewhat underwhelmed by these tools - I have always felt > that a good tool (eg text editor, ide etc.) should allow you to work about > as fast as you can enter data, and this is just not the case with the > schematic capture tools I have used. > > So my question is: Does anyone know of a powerfull, flexible schematic > editor with decent (preferably configurable) key bindings, rock like > stability, a nice user interface, highly intuitive, that is fast and a > pleasure to use etc? > > One that uses an HDL description of each schematic behind the scenes ECS > style is probably a plus. > > Or should I just be gratefull I'm not directly entering netlists... ;-) > > Cheers, > Chris Saunter Hi Chris, Like you when I started in HDL I thought that the ideal approach is a top level schematic to show how the HDL interconnects. I stared using the Xilinx tools but found them time consuming for a large design. I ended up having top level VHDL and a pencil schematic because this was quickest and with a rubber the most flexible. The consensus seems to be that the future lies in all HDL designs but I find this uncomfortable having been brought up on a whole array of beautiful hardware block diagrams and schematics that make everything visible at a glance. It does seem to be true that any EDA drawing tool becomes horrendously complex even without linking it to logic functionality. Any knowledge or skills will have limited portability into the future. I am currently experimenting with working in VHDL as far as possible and using something as simple as Microsoft Excel to draw block diagrams of modules. Interconnects are not explicitly drawn but shown by common labels. Modules can be expanded on separate sheets. There is also a nice array of colours and shading that can make it all clear. Cut and paste is easy, nearly every PCs can run excel and most people can drive the package. Its a bit tedious to get exactly what you want but like I say all EDA becomes tedious ( cue the deluge of "no it doesn't"). So far so good, but I may scrap it all tomorrow. Good luck on your journey. Regards Phil -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 41703
On Thu, 04 Apr 2002 20:15:11 -0600, Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote: >(I already figured >out how that secret PCILOGIC thing works, and I only now need to know >how Bitgen's /Gclkdel option works to insert more delay on the global >clock buffer . . . ) > > .... > >However, this "It's an FAE's tool" mentality seems to create a myth that >only Xilinx or really experienced users can use it, and that myth seems >to be similar to a PCILOGIC myth people talk about when a question comes >up about "The special IRDY and TRDY pin for PCI in Virtex." >People always say only Xilinx knows how PCILOGIC works, but should I >shatter the PCILOGIC myth for once and for all by posting a sample code, >and some explanation on how to instantiate it and actually use it? > Before you hurt your self with too much patting yourself on the back, you might want to look at this, from a year ago: http://www.fpga-faq.com/archives/30000.html#30017 and http://www.fpga-faq.com/archives/30000.html#30018 Not much of a secret really. :-) :-) :-) But /Gclkdel is a different story. Maybe you should write an explanation for inclusion in the FAQ?? =================== Philip Freidin philip@fliptronics.com Host for WWW.FPGA-FAQ.COMArticle: 41704
For a tutorial (somewhat dated, but a reasonable intro) you might want to look at: http://www.fliptronics.com/floorplanning1.html and to see some really beautiful examples of floorplanning you can see them at http://www.fliptronics.com/gallery.html In particular, the designs MFILT, DVB_DEMOD, LINEAR, and FORMATTER show what can be achieved. Philip Freidin FliptronicsArticle: 41705
> 2: How much learning does it mean to those engineers who is never willing to > learn new stuff, for example > those above 30 years old? > Kelvin, Just remember, someday you will be above 30 years old, if you are lucky. NewmanArticle: 41706
I am currently looking at two solutions to a frequency generation problem. Either I can use a PIC microprocessor or a CPLD (Xilinx XCR3256XL). The PIC includes a crystal oscillator on chip. What I am wondering is, can I use some gates from the CPLD to create an embedded crystal oscillator rather than having to include an external design based around a couple of inverters in a discrete logic chip. Has anyone done this already? I haven't been able to gather much from the Web or news groups so far. Many thanks in advance JackArticle: 41707
Hi, How to build a digital PLL in VHDL to extract clock and data from an incoming NRZI signal ? Thanks. -- Roberto Capobianco Consorzio RFX - CNR di Padova C.so Stati Uniti, 4 35127 - Camin (PD) email: capobianco@igi.pd.cnr.it web: www.igi.pd.cnr.it tel.: +39-049-8295048 fax: +39-049-8700718Article: 41708
Jack Nimble wrote > Either I can use a PIC microprocessor or a CPLD (Xilinx XCR3256XL). > > The PIC includes a crystal oscillator on chip. What I am wondering is, > can I use some gates from the CPLD to create an embedded crystal > oscillator rather than having to include an external design based > around a couple of inverters in a discrete logic chip. Could become a FAQ. Look in the archives for previous reponses. Don't do it - you don't know enough about the PAL pin structures. Only the device manufacturer has the key info to make a _reliable_ design. $1.36 clock drivers can be bought from ICS, or use the LT app note to cook up a design with a transistor.Article: 41709
What is the bit time or frequency? Do you have a re-synchronizing start bit? What is the max run length? What kind of timing source or oscillator do you have available, and what is its stability? Peter Alfke ================================ Roberto Capobianco wrote: > Hi, > How to build a digital PLL in VHDL to extract clock and data from an > incoming NRZI signal ? > Thanks. > > -- > Roberto Capobianco > Consorzio RFX - CNR di Padova > C.so Stati Uniti, 4 > 35127 - Camin (PD) > email: capobianco@igi.pd.cnr.it > web: www.igi.pd.cnr.it > tel.: +39-049-8295048 > fax: +39-049-8700718Article: 41710
Peter Alfke wrote: > What is the bit time or frequency? My bit time is 40ns > Do you have a re-synchronizing start bit? Yes. I want to use HDLC flag (01111110) to synchronize the receiver and NRZI code with bit stuffing for data >What is the max run length? The max frame lenght is about 50 bits but transmission is burst like (flag+data+pause+flag+data+pause.........) >What kind of timing source or oscillator do you have available, and what is its stability? 100 MHz oscillator -- Roberto Capobianco Consorzio RFX - CNR di Padova C.so Stati Uniti, 4 35127 - Camin (PD) email: capobianco@igi.pd.cnr.it web: www.igi.pd.cnr.it tel.: +39-049-8295048 fax: +39-049-8700718Article: 41711
Hi !
Does somebody know what are the technical differences between the "Parallel
cable III" and the "Parallel cable IV"?
Technical means, are the pinouts at the DB25 connector changed?
Esp. i'm interested in lpt-pins 2, 3, 4, 5, 6 and 13.
Is there a schematic available for the Parallel cable IV ???
It's really, really IMPORTANT !!!
Thanks in advance.
Best regards,
Jens Frauenschlaeger
----------------------------------------------------------------------------
----------------------------
Jens Frauenschlaeger - conny@informatik.uni-leipzig.de
University of Leipzig
Germany
Article: 41712
I think a more detailed description of what Amplify does is in order.
The logical hierarchy of a design can be easily reorganized into
a good physical hierarchy without touching the source code. This
may not matter to some people who thought physically from the
beginning of their design and have the experience to know up front
what the organization should be. Part of this reorganization
capability includes the ability to replicate chunks of RTL objects.
You may find that replicating an FSM or counter into different parts
of the chip yields large improvements.
Because the floorplan definition in Amplify is at an RTL level and we
worked very hard at making generated RTL object names repeatable even
with design changes, the RTL floorplan can survive design changes.
Gate level floorplans that don't stick to module boundaries often have
to be redone for even trivial design changes. (If you are doing
structural netlisting in your HDL and generating placements, then that
would be an exception). Amplify will also perform boundary optimization
on your floorplan which involve timing optimizations mixed with
placing results back into the regions.
The current version of Amplify (3.0) includes a full detail placer for
regions that works in cooperation with timing optimization of the logic.
This feature is currently only available for Virtex/VirtexE. Detail
placement obviously gives Amplify much more accurate delay information.
An experienced Amplify user can get substantial performance improvements
in 3-5 iterations through P&R. The first iteration gets you calibrated
and the following iterations are like a game of whack a mole where the
mole doesn't come back up again.
Amplify obviously works best when the critical paths in your design are
through a chunks of RTL. If you are willing to do a structural design
and hand place everything, then it won't be useful to you. Most designs
aren't done that way.
Ken McElvain CTO
Synplicity, Inc.
Ray Andraka wrote:
> Frankly, I don't see the cost justified by the marginal added value with
> amplify. You can do almost* everything it does with the area constraints in
> the floorplanner, plus with the floorplanner you can lock down some and area
> constrain other logic.
>
> *The one thing it does buy you is to take into consideration the layout
> while doing the synthesis.
>
> Like you mention, there was a time when we did floorplanning with graph
> paper. The GUI makes it easier, but I still use the graph paper method for
> doing placement in the source.
>
>
> Phil Hays wrote:
>
>
>>Jimmy Zhang wrote:
>>
>>
>>>Just keep hearing about this hand placement thing, don't know how it
>>>is done in reality. Does someone actually use their hands to do the
>>>placement as opposed to CAD based P&R. Any hints?
>>>
>>The first way I learned to do this was with a paper diagram of the
>>target chip, writing the constraints with a text editor, and coloring on
>>the paper to indicate what had been put where. I didn't do the best of
>>jobs (had an register reversed, with the msb where the lsb should be),
>>but it was still ~30% faster resulting clock speed than the automatic
>>placement. Made place and route times drop nicely as well. It was even
>>better than that once I got the twist removed. But this is as close to
>>"by hand" as I can picture.
>>
>>The floorplanner that Xilinx provides is just a nicely automated way of
>>doing the same sort of puzzle. Do the data path(s) first, fit things
>>together in a "logical" fashion, and for the first one floor plan at
>>least plan on spending some time fiddling. Some people seem to get this
>>skill right away, and some take longer.
>>
>>A slightly "higher level" way of gaining much of the benefit from
>>floorplanning with potentially rather less effort is to use a "physical
>>design" tool. Synplicity had the first ("Amplify") aimed at FPGA design
>>(and I'm not sure if Mentor, Synopsys or anyone else have anything in
>>this space yet), however there were physical design tools for ASIC
>>design long before Amplify. These work by putting large chunks of the
>>design into subsections of the target chip.
>>
>>Synopsys's ASIC physical design tool set:
>>
>>http://www.synopsys.com/products/phy_syn/phy_syn.html
>>
>>Amplify is at:
>>
>>http://www.synplicity.com/products/amplify.html
>>
>>--
>>Phil Hays
>>
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
> "They that give up essential liberty to obtain a little
> temporary safety deserve neither liberty nor safety."
> -Benjamin Franklin, 1759
>
>
>
Article: 41713Please, please... Tell me what constructs I can manually edit into my edif file to produce orderly layout! If the synthesis tool isn't giving the P&R the info it needs to get the job done, what can I possibly do to have the P&R do better than the fumbling I get now? Nicholas Weaver wrote: > I actually assert that a lot of the problem is right in the synthesis, > not in the P&R: There has been a lot of work which has been done on > work which, given a datapath, constructs an orderly layout. Yet none > of this seems to have found its way into the commercial synthesis > toolflows. So much informtion is thrown away.Article: 41714
I'm relatively new to V2 design, so this is probably very basic. Warning : CLKFX_DIVIDE = 2 is not 1 ... 32. Warning : CLKFX_MULTIPLY = 4 is not 1 ... 32. Warning : CLKFX_DIVIDE = 1 is not 1 ... 32. Warning : CLKFX_MULTIPLY = 4 is not 1 ... 32. any clues?Article: 41715
Hello Sajjad, This is a known issue and the message can be ignored. The issue will be resolved in Service Pack 2 of the ISE software, tentatively due in mid-April. Regards, KamalArticle: 41716
Let me start by saying thanks for providing the Synplify tool to the market. Compile times are great and the results are reasonable though I still have my troubles with every design. I need to hand-tweak much less of the code than with other tools I've used in the past. Ken, you have my respect. The replication of chunks of RTL is potentially helpful: it save the manual replication I regularly do by hand in my code for a good hour or two savings in a large project. Thank you for working "very hard at making generated RTL object names repeatable even with design changes" since this is the biggest open sore of the tool that I actually own. I just wish it could benefit me. (more below...) Ken McElvain wrote: <snip> > An experienced Amplify user can get substantial performance improvements > in 3-5 iterations through P&R. The first iteration gets you calibrated > and the following iterations are like a game of whack a mole where the > mole doesn't come back up again. I've suggested in the past that my 8 year old nephew could get just about as good results using Amplify as an engineer with intimate knowledge of the design. I leave it to you to decide if this is praise for the ease of use of the product or a criticism of the tool to take that "extra step" and decide on the area optimizations itself. I realize the Amplify tool has a market because of the inadequacies of the Xilinx P&R tools but it also has a place because Synplify falls short of allowing us to do the light work ourselves.Article: 41717
"Jens Frauenschlaeger" <conny@informatik.uni-leipzig.de> schrieb im Newsbeitrag news:a8khfq$o9s$1@news.uni-leipzig.de... > Does somebody know what are the technical differences between the "Parallel > cable III" and the "Parallel cable IV"? > Technical means, are the pinouts at the DB25 connector changed? > Esp. i'm interested in lpt-pins 2, 3, 4, 5, 6 and 13. > Is there a schematic available for the Parallel cable IV ??? I dont know. But since the parallel cable III is just a serial thing (JTAG or Slave Serial Download), its rather slow. I guess Parallel cable IV is a small CPLD (an Altera one ;-) wich just works as a parallel serial converter. The parallel port should run in EPP mode, giving up to 2 Mbyte/s troughput. Serialized, this gives 16 Mbit/s. Iam sure it could be build using a 32 macrocell CPLD. > It's really, really IMPORTANT !!! Does the fate of earth depend on it? ;-) > Jens Frauenschlaeger - conny@informatik.uni-leipzig.de > University of Leipzig > Germany Hello to Leiptzsch von Dräääsden. ;-) -- MfG FalkArticle: 41718
Philip Freidin wrote:
>
> On Thu, 04 Apr 2002 20:15:11 -0600, Kevin Brace
> <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote:
>
>
> Before you hurt your self with too much patting yourself on the
> back, you might want to look at this, from a year ago:
>
Not a very nice comment.
> http://www.fpga-faq.com/archives/30000.html#30017
>
> and
>
> http://www.fpga-faq.com/archives/30000.html#30018
>
When I figured it out how to instantiate it from XST, I used the
information from the following website.
http://www.opencores.org/forums/pci/2001/09/00003
The problem was, the guy who did the analysis didn't post the code he
wrote, and it wasn't in Verilog. (I am a VHDL hater.)
Until I thought of cracking the PCILOGIC secret, I never used a blackbox
in my code (Now I use it. It is a very useful feature.), so I had to
learn that, and not having an initiator/target PCI IP core (It was a
target only one at that time.) to play around with at the time also
caused some problems when I experimented with it.
> Not much of a secret really. :-) :-) :-)
>
Before reading that opencore.org conversation, I have already
done a Google Groups search of this newsgroup, but I didn't find any
useful information about PCILOGIC at that time.
Only after I figured out how the PCILOGIC works, I noticed that the
equation inside was indeed discussed at this newsgroup.
I didn't used to visit this newsgroup at the time it was discussed
either.
I find it surprising that Eric Crabill of Xilinx who supposedly works
with LogiCORE PCI at Xilinx publically admitting the equations inside.
Isn't that supposed to be a trade secret of Xilinx?
PCILOGIC may not be a huge secret to you, but a question about
it seems to come up once every two months or so, and people who answer
it keeps saying that it is a secret feature only Xilinx knows.
Yes, if you ask a Xilinx employee about it, they won't tell you at all
saying that it is an undisclosed feature.
So, I will still call it a secret feature, but I already got it.
After I figured it out how it works, it turns out there is really no big
deal other than unregistered long signal paths (unregistered IRDY# and
TRDY#) leading to CE (Clock Enable) input of IOB output FFs will not
cause timing problems during P&R.
So, there is really not big deal, and I will like to shatter that myth
that it is some kind of a magic box.
> But /Gclkdel is a different story.
>
All the publically available Xilinx documents say, "Don't use it
unless you are instructed by Xilinx."
Trying to keep something secret, of course, makes me more interested in
knowing about it.
Supposedly, the customers of their 66MHz PCI IP core know how to use it
according to LogiCORE PCI implementation document, because they are
required to use it in order to meet Tsu < 3ns.
One concern I have with a /Gclkdel option is that it is added after a
static timing analysis is done, so the static timing analyzer's numbers
won't reflect the /Gclkdel option.
> Maybe you should write an explanation for inclusion in the FAQ??
>
> ===================
> Philip Freidin
> philip@fliptronics.com
> Host for WWW.FPGA-FAQ.COM
Yes, if it is possible, I will rather have a sample code, a
constraint file, and the analysis of how it works included in the FPGA
FAQ than simply being posted to this newsgroup because that way, people
can refer to the FAQ rather than having to search this newsgroup.
Where should I send all the information?
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 41719Thanks, Philip for the information. Why not update the information to cover Virtex architecture FPGAs? I believe I already know the basics of floorplanning in Virtex architecture FPGAs because I had to floorplan my design to meet Tsu < 7ns requirement of 33MHz PCI a few months ago. Although I no longer have to do so now because of design improvements I made. Several times in the past, I have "tried" to get my PCI IP core to meet Tsu < 3ns in Spartan-II-6, and, of course, I had to manually floorplan very timing critical unregistered control signal paths. (i.e., unregistered DEVSEL#, TRDY#, and STOP# to FRAME# and IRDY IOB FFs.) I came within about 15% of meeting Tsu < 3ns after tying two global clock buffers in series to artificially generate more setup time. (I consider this an alternative to Bitgen's /Gclkdel option, but I am not sure how reliable it is.) Likely, Virtex-E-7 might make it if everything works out, but I haven't tried that yet. However, the problem I am having here is not with the Xilinx Floorplanner, but with Quartus II 2.0 Web Edition's floorplanner, and do you know any online resources about it? I guess Altera users don't use floorplanner that much like some Xilinx users do, but for things like PCI, I think it is very important. Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.) Philip Freidin wrote: > > For a tutorial (somewhat dated, but a reasonable intro) you > might want to look at: > > http://www.fliptronics.com/floorplanning1.html > > and to see some really beautiful examples of floorplanning > you can see them at > > http://www.fliptronics.com/gallery.html > > In particular, the designs MFILT, DVB_DEMOD, LINEAR, and > FORMATTER show what can be achieved. > > Philip Freidin > FliptronicsArticle: 41720
On Fri, 05 Apr 2002 13:57:12 -0600, Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote: >Philip Freidin wrote: >> >> On Thu, 04 Apr 2002 20:15:11 -0600, Kevin Brace >> <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote: >> >> Before you hurt your self with too much patting yourself on the >> back, you might want to look at this, from a year ago: > > Not a very nice comment. Oh, come on! I know that other have written personal attacks that were uncalled for, but this hardly counts. How much more gentle could I have been? The info is available, it's in the archive, anyone can see it. >> Not much of a secret really. :-) :-) :-) > > Before reading that opencore.org conversation, I have already >done a Google Groups search of this newsgroup, but I didn't find any >useful information about PCILOGIC at that time. >Only after I figured out how the PCILOGIC works, I noticed that the >equation inside was indeed discussed at this newsgroup. >I didn't used to visit this newsgroup at the time it was discussed >either. Well, that doesn't make it a secret. Just an undocumented feature of the chip. Others have reverse engineered its functionality and published the info in this news group. >I find it surprising that Eric Crabill of Xilinx who supposedly works >with LogiCORE PCI at Xilinx publically admitting the equations inside. Typical Xilinx person being helpfull. >Isn't that supposed to be a trade secret of Xilinx? Who supposes? Not much of a trade secret if it has been published. Since Xilinx tools even output a simulation model for it for post P&R simulation, there is no way it could be considered a secret. Just poorly (i.e. not at all) documented. > PCILOGIC may not be a huge secret to you, but a question about >it seems to come up once every two months or so, and people who answer >it keeps saying that it is a secret feature only Xilinx knows. Who said that ??? Show them too me !!! I'll give them the URL too. >Yes, if you ask a Xilinx employee about it, they won't tell you at all >saying that it is an undisclosed feature. More likely, they just don't know. Xilinx probably has 2000 people, and of them only 6 people (approx) know the details: The Product Planner The I.C. designer The I.C. test engineer The SW QA engineer The SW engineer that created the simulation model The engineer in the IP group that created the PCI cores. If you talk to any of the other 1994 people, they will look at the same info you have access to, and wont find an answer. Then they might answer "It must be a secret". Just like the secret that you can do higher quality designs with schematics and hierarchial floorplanning. And timing based simulation is unnecessary if you have done fully synchronous design and have 100% coverage of timespecs with static timing analysis. >So, I will still call it a secret feature, but I already got it. Good enough. >After I figured it out how it works, it turns out there is really no big >deal other than unregistered long signal paths (unregistered IRDY# and >TRDY#) leading to CE (Clock Enable) input of IOB output FFs will not >cause timing problems during P&R. >So, there is really not big deal, and I will like to shatter that myth >that it is some kind of a magic box. > >> Maybe you should write an explanation for inclusion in the FAQ?? >> >> =================== >> Philip Freidin >> philip@fliptronics.com >> Host for WWW.FPGA-FAQ.COM > > > Yes, if it is possible, I will rather have a sample code, a >constraint file, and the analysis of how it works included in the FPGA >FAQ than simply being posted to this newsgroup because that way, people >can refer to the FAQ rather than having to search this newsgroup. Sure it is possible. >Where should I send all the information? Go to http://www.fpga-faq.com/FAQ_Root.htm , and at the bottom of the page, down load the template of a FAQ page. Then fill in the page the way you would like it to be, and email it to philip@fpga-faq.com If you need help doing this, let me know. It will be published for all to see in the FAQ, and will not be a secret anymore. You may want to look at some other FAQ pages, to get a feel for the current style. This is also an open invitation to everyone else to write some FAQ pages. It is only as good as the sum of the contributions !! Philip Freidin Philip Freidin FliptronicsArticle: 41721
Patrick,
The following Verilog code should implement the design that you have
described below. I have targeted it to a QuickLogic QL3012 device in a -1
speed and it reports a 46 Mhz worst case speed. A -2 device should run over
50 Mhz. If you would like a programmed sample of the device I could arrange
to have one shipped to you. The good thing about QuickLogic is they will
provide the devices pre-programmed, no need to but a $1000 programmer.
Chuck Levin
module pwm(data_in, clk, rst, we, sel, pwmout);
input [31:0] data_in;
input clk, rst, we, sel;
output pwmout;
reg [31:0] rega, regb, regc;
reg pwmout;
always @(posedge clk or posedge rst)
begin
if(rst)
begin
rega <= 32'b0;
regb <= 32'b0;
regc <= 32'b0;
pwmout <= 1'b0;
end
else
begin
regc <= rega + regc;
if(we && !sel)
rega <= data_in;
if(we && sel)
regb <= data_in;
if( regc > regb)
pwmout <= 1'b1;
else
pwmout <= 1'b0;
end
end
endmodule
"Patrick Robin" <circaeng@hotmail.com> wrote in message
news:3CADD0A8.9D605257@hotmail.com...
> Hi,
>
> I am new to this field. I am a senior software engineer with some
> college experience in basic digital design from 12 years ago.
>
> I also have experience programming AVR Atmel uC.
>
> I am contemplating moving one of my uC design to part hardware, part
> software to increase speed. It consists in a frequency and pulse width
> adjustable square wave generator.
>
> I would apreciate your opinion on how difficult and costly ($) would it
> be for someone like me to design a hardware (chip) with:
>
> -a 32 bit accumulator
> -a 32 bit comparator
> -one 32 bit register (A) to store the number to be added by the
> accumulator
> -one 32 bit register (B) to store the number to compare against the
> accumulator sum (C)
> -one digtal output =1 if C>B 0 otherwise or vice versa
>
> The accumulator should run at least at 25MHZ, preferably 50MHZ
>
> I could probably do this with individual components but I want to
> minimize part count. Please let me know of the best way to approach
> this. I don't want to invest in costly ($1000) programmators if
> possible.
>
> Of course if you already know of such a chip I would like to know also
> :)
>
> Thanks for your time.
>
> Patrick
>
>
Article: 41722Hi, Kevin Brace wrote: > I find it surprising that Eric Crabill of Xilinx who supposedly works > with LogiCORE PCI at Xilinx publically admitting the equations inside. > Isn't that supposed to be a trade secret of Xilinx? I don't supposedly work at Xilinx, I actually work at Xilinx, in the IP Solutions Group, developing IP. I am, in a tangential way, associated with the PCI and PCI-X cores... I wouldn't call it a trade secret. You may find the general invention patented and assigned to Xilinx, however. The implementation in Virtex, Spartan-II, Virtex-E, and Spartan-IIE is the same and intended to assist implementation of PCI cores in these devices -- the logic implemented is quite literally a tiny part of our core cast into silicon (and, in the grand scheme of things, immaterial; the real advantage of this "feature" is the dedicated routing associated with it). This feature is, however, undocumented, unsupported, and not intended for general use. It is supported in the context of the Xilinx PCI LogiCORE. The feature was put in the silicon by the request of the PCI Development team, for use by the PCI Development team. If you use it in your own designs, that is fine. However, if you run into problems/issues, you are on your own -- the feature is undocumented and unsupported. If you were to file a case with the Support Hotline, they probably won't be able to help you directly. Such a case would most likely be forwarded to me, and I would write back, "This feature is undocumented, unsupported, and not intended for general use. Sorry." > So, there is really not big deal, and I will like to shatter that myth > that it is some kind of a magic box. I prefer to think of it as a magic box. In fact, the instance name of it in our core is "MAGICBOX". Maybe that is where the notion came from... Anyone who is really interested can determine the logic function using the publically available tool set. Likewise, if you are very curious about the GCLKDEL option, you can experimentally determine what it does. EricArticle: 41723
Philip Freidin wrote: > More likely, they just don't know. Xilinx probably has 2000 > people, and of them only 6 people (approx) know the details: > > The Product Planner > The I.C. designer > The I.C. test engineer > The SW QA engineer > The SW engineer that created the simulation model > The engineer in the IP group that created the PCI cores. Even less, if by chance one person did, say, three or four of those things... You are all trying to steal my magic bag! EricArticle: 41724
Ya, it should work no problem. All you need is an inverting amplifier (i.e. not gate in the CPLD) and a suitable feedback network (crystal or resonator, and 2 caps) and you should be on your way. The accuracy of your time base will be effected by how well you tune it. But as another poster said, canned oscillators are cheap and plentiful, so you better be building this sucker in quantity to justify reinventing this wheel. Regards news:<e0e065dd.0204050453.399de84@posting.google.com>... > I am currently looking at two solutions to a frequency generation > problem. > > Either I can use a PIC microprocessor or a CPLD (Xilinx XCR3256XL). > > The PIC includes a crystal oscillator on chip. What I am wondering is, > can I use some gates from the CPLD to create an embedded crystal > oscillator rather than having to include an external design based > around a couple of inverters in a discrete logic chip. > > Has anyone done this already? > > I haven't been able to gather much from the Web or news groups so far. > > Many thanks in advance > > Jack
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