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
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:43dab9ea$1@clear.net.nz... > Antti Lukats wrote: > >> Hi all >> > <snip> >> also coming are are sub 3 (and even sub 2) USD low cost small package >> versions >> of the power supply monitor and supervisory circuits > > These needed to come down in price - at the silly prices they were, > they were never going to hit mass support - just the odd VHDL designer who > was unable to get a small uC and a couple of FETs to do the same thing. > The newest tiny system uC, like the Tiny2313, newest ST7 lite, and > Atmel LP216, are all in the 80c region, and you keep getting more for > your 80-90c.... > > All Lattice needs now, is to work out how to turn a profit :) > > -jg > yes you right, the power managers (PawerManager II - 7USD) are too expeensive so thats why they have planned products priced below 2 USD for that market. well lets see if they actually come, hum but I dont think the lattice powermanaers will drop below 1 USD in price so they can miss the bottom high volume market again, AnttiArticle: 96026
Brian Davis wrote: > I've sucessfully done this sort of thing in V2-ish parts using one > of the nifty _DIFF_OUT buffers ( or hand built equivalent) to create > complementary local clocks to the DDR IOB registers (XAPP609), > with the next CLB register stage constrained only by a MAX_DELAY, > and the DCM clocks only used for the half rate logic. First of all, typo in the original posting: it's 840MBps, not 480Mbps I have to deal with. Then on to your suggestion: Sounds good, but the half-rate logic would still be running at 210MHz in my case. I need more deserializing, need to make it slower :) The thing is that the ADC sends out a 420MHz clock and a 70Mhz clock along with the data. So obviously this is designed so that you run some deserializing circuit with the 420MHz, and clock out the parallel data with the 70MHz clock. Plus, you'd do the rest of the processing in the FPGA with the 70MHz, which is easily handled. > This makes it fairly easy to hit IOB DDR timing without needing > any funky DCM phase shift delay calibration logic, only LOC's on > the I/Os to the proper local clocking region. The latter is the biggst constraint. In the first board we did, the clocks weren't connected to the local clocking pins. But even if they were, at 840Mbps (sorry, typo in the original posting, it's 840, not 480!), I still needed to do some calibration in every case. At these speeds you're already getting problems if the traces on the board aren't closely matched. I could never get it to work reliably (i.e. considering temperature drift etc.) without phase-shifting and re-calibration from time to time. > At 480 Mbps, I'd advise sticking with LVDS & DT terminators. That's what I thought. cu, SeanArticle: 96027
Erik Widding wrote: > Use the ISERDES setup you describe here to get 6 bits at a time. > Really quick pseudo code for a solution: > > signal left : std_logic_vector ( 5 downto 0); > signal sample : std_logic_vector ( 11 downto 0); > > if ( falling_edge( sample_clock ) ) then > left <= ISERDES_out(5 downto 0); > end if; > > if ( rising_edge( sample_clock ) ) then > sample <= left && ISERDES_out(5 downto 0); > end if; > > Sample clock needs to be properly phased to the ISERDES output, and a > timing constraint with 1/2 the period of sample_clock is placed between > ISERDES_out and the two destination registers. The tools will take it > from here. I see what you're getting at. But I'd still need to supply the ISERDES with a 1/3-divided clock to get a 6bit-output (this is the clock the ISERDES output is registered with). That clock I don't have, I'd need to use a DCM or something to generate it. The sample clock on the other hand I get from the ADCs along with the data. The whole point of using the ISERDES is to save on clock nets, DCMs etc., and simply use what I'm supplied with. cu, SeanArticle: 96028
dp wrote:
[ ... ]
> The number of things which can be done is probably infinite. However,
> programmability is a major feature of programmable devices - or at
> least I naively thought so until today :-).
Oh, it certainly is.
His point (and I agree that it's valid) is that sometimes things that
need changing aren't in the FPGA itself. Just for example, if you
decide to add some sort of extra I/O to some hardware, you're typically
going to need some sort of physical connection. Putting an Ethernet MAC
into your FPGA is pretty straightforward, but won't do much good
without the physical hardware to allow the user to connect his Ethernet
cable.
That particular change would really be in design scope rather than
indicating a defect in the implementation though. Perhaps a more
reasonable example would be that the design had Ethernet all along,
with the MAC on the FPGA, but the PHY as a separate chip. A problem in
the PHY chip might be curable by changes in the FPGA.
At the same time, a lot of ancillary chips like this tend to have
relatively simple requirements, reducing the likelihood of subtle
problems in their designs -- and sometimes even if there is a problem
in such an ancillary chip, you can assure against putting it into the
situation where the error arises.
--
Later,
Jerry.
Article: 96029"Yaju Nagaonkar" <yaj_n@hotmail.com> schrieb im Newsbeitrag news:1138412013.300497.46010@o13g2000cwo.googlegroups.com... >I am not yet done with my debugging yet, but thought would find out if > anyone out has experimented with slave serial configuraiton of > Spartan3. > > Here is the setup on my PCB board. 1) you can use impact to query the configuraton status after your config attempt, as example you can see if there was CRC error, etc. but my bet it only say init ok, done = 0 2) make sure you have startupclock set CCLK 3) if in doubt reverse bit order in bytes 4) send some more dummy bits after end I am using mega8 to load Spartan3 and virtex4 over JTAG from SD-Card and I have no problems. slave serial is even simpler to implement, just send the .BIT file into DIN and that should do it note that INIT will not flag error if the proper signature is never seen AnttiArticle: 96030
On Fri, 27 Jan 2006 11:20:42 +1000, John Williams <jwilliams@itee.uq.edu.au> wrote: >You know, there's just not enough talk about cricket on comp.arch.fpga. > >Perhaps a new group - comp.arch.fpga.cricket? > >John (who travels past the 'Gabba every day on the way to work...) I walk out my front door and I look at the MCG. Regards, AllanArticle: 96031
Sean Durkin schrieb: The whole point of using > the ISERDES is to save on clock nets, DCMs etc., and simply use what I'm > supplied with. The point of the ISERDES is to meet timing that you would not with a LUT based SERDES. The point of the IO delay lines is to save DCMs and clock nets. Without them you would need a DCM per ADC anyway to do the phase alignement, even if you could use the frequency 1:1. Kolja SulimmaArticle: 96032
Sean Durkin schrieb: > The thing is that the ADC sends out, along with the data, a fast clock > and a 6x slower clock. If you run the ADC at 70MHz, it sends back a > 420MHz clock and a 70MHz clock. The whole thing is designed so you use > the 420MHz to clock some sort of deserializing-circuit and the 70MHz to > clock out the parallel data and do your processing. So that's the > "intended" way to handle this, and of course you'd first look for a way > to do it with what you're provided with. > > Now, since one single ISERDES doesn't handle DDR, it would have to be > run at 840MHz, plus I'd need to waste a DCM to double the clock (can > they even get up to 840MHz?) I get from the ADC. No way. Alternatively, > I could use two ISERDES in Master-/Slave-Mode (then they can handle DDR) > to output two 6bit-nibbles, as you suggested. But to get these out, I'd > have to have a 140MHz clock, which I don't have. Again, waste a DCM to > generate it. And since I normally have 4 of those ADCs hooked up to one > FPGA, that's 4 DCMs gone already, in addition to the 4 I need to do > phase-shifting anyway. That's 8 total, which is probably every single > one available in the devices I have available. Again, no way. > > The whole point of using the ISERDES in the first place is to save on > DCMs, clock nets and hand-placed components, to make do with what is > readily available. > > I still don't see where the ISERDES would make anything easier. For those ADCs it is not necessary to route both the full clock and the 1/6 clock to the FPGA. You have a phase shift in every pin of virtex-4, use that to do your phase alignement. If a DCM can go to 840 MHz with clock FX you can get the 840MHz, 70MHz and 140MHz for all ADCs out of a single DCM. If it can not you can use an ISERDES in master slave mode to get 2x3=6 bits still using only one DCM total for an unlimited number of ADCs. Kolja SulimmaArticle: 96033
Jerry Coffin wrote: > His point (and I agree that it's valid) is that sometimes things that > need changing aren't in the FPGA itself. Just for example, if you > decide to add some sort of extra I/O to some hardware, you're typically > going to need some sort of physical connection. Putting an Ethernet MAC > into your FPGA is pretty straightforward, but won't do much good > without the physical hardware to allow the user to connect his Ethernet > cable. Actually, I tend to run unused I/O's to a header very close to the Fpga that can take a daughter card. This does allow for easy external additions after the project is "done".Article: 96034
Simon Peacock wrote:
> I think you are taking the wrong approach. I'm sure you can get the C code
> running. But in reality if you have to implement sin/cos & sqrts, then the
> C code will be far from optimal, and you might need a vertex to do the job
> of a Spartan
Actually, I find it not that different in many cases from similar
VHDL/Verilog
and have the advantage of being able to tweek the output in FpgaC when
I don't like it. Especially when I do a boolean design, it goes right
thru FpgaC
as boolean logic equations to the LUT. The C may look a bit ugly that
way, but
you certainly have nearly exact control over the output. For example:
[jbass@fastbox tests]$ cat example1.c
int a:1,b:1,c:1;
#pragma inputport (a,a9)
#pragma inputport (b,a10)
int sum_of_products:1;
#pragma outputport (sum_of_products,a11)
main()
{
c = (sum_of_products = (a&b) + c);
}
produces:
[jbass@fastbox tests]$ fpgac -target cnf example1.c
[jbass@fastbox tests]$ cat example1.cnf
_example1_Running^CLK = VCC;
_a^CLK = port(_a,"a9");
_b^CLK = port(_b,"a10");
_c^(CLK*_example1_main__state_C1) = (~_c*_b*_a)+(_c*~_a)+(_c*~_b);
port(_sum_of_products,"a11")^(CLK*_example1_main__state_C1) =
(~_c*_b*_a)+(_c*~_a)+(_c*~_b);
_example1_main__state_C1 = ~_example1_Running;
which in xnf/edif is a bit more verbose (so I'll just take the meat of
it):
SYM, _sum_of_products-OBUF, OBUF
PIN, I, I, _sum_of_products
PIN, O, O, sum_of_products
END
EXT, sum_of_products, O,, LOC=_a11
SYM, FFin-_sum_of_products, EQN, EQN=((~I0*I1*I2)+(I0*~I2)+(I0*~I1))
PIN, I2, I, _a
PIN, I1, I, _b
PIN, I0, I, _c
PIN, O, O, FFin-_sum_of_products
END
SYM, _sum_of_products, DFF
PIN, D, I, FFin-_sum_of_products
PIN, C, I, CLK
PIN, CE, I, _example1_main__state_C1
PIN, Q, O, _sum_of_products
END
Article: 96035Larry Doolittle wrote: > Second concern: can open source software be published that > works with XDL? IANAL (honest), but we have to look at this > from a lawyer's perspective. On the open source side, we > have "The Open Source Definition" The answer unfortunately is that the EULA NDA restrictions and open source are mutually exclusive. The EULA NDA is so resrictive that you can not even talk to anyone about your "performance" with the experience as benchmarking includes everything from bugs, to comparitive results, to non-comparitive objective results. Because the EULA is a contract between you and Xilinx, it even prempts the normal rights you would have if the same information was in a book that you could purchase in a public book store. This is made obvously clear when the EULA prohibts benchmarking, and goes right to the core of even being able to talk about the product in specific details. Any expectations about fair use, or rights under copyright law just vanish.Article: 96036
Larry Doolittle wrote:
> That will generate a legal flap akin to deCSS, and
> unfortunately will cause Xilinx to reconsider its public
> XDL support.
In another thread I pressed Austin for an answer which he said his
reading (as does yours and mine) is that the EULA prohibts open source.
I've updated the FpgaC users manual to include this, and asked Austin
for his input, which he declined ... not a suprise as it gets too close
to
legal, which is where probably where he forwarded my request.
Given the obvious conflict this creates in the Xilinx developers
community
with open source, the company legal department really needs to make a
clear an definative statement that is given to rank and file Xilinx
Staff so
that they may avoid miss-representing the current legal state, and have
the guidance to communicate that clearly to customers.
Another Xilinx employee, Ed McGettigan saying that copyright law
protects
you from the EULA, there clearly is a unified message problem from
Xiinx
that could very unfairly trap open source developers in a legal fight
with
Xilinx.
John
> From jbass Fri Jan 27 14:59:57 2006
> To: austin.lesea@xilinx.com, jbass
> Subject: Need your review and suggestions
Hi Austin,
The following text has been added to the FpgaC user manual, to call
attention to the Licensing restrictions involved. I hope this fairly
and accurately documents the challenges we currently face working
with the Xilinx EULA.
Please feel free to make or suggest any changes that you feel would
better describe the current problems, and better support Xilinx and
your customers. FpgaC would like this to go well for both our project
and Xilinx.
Thanks,
John Bass
-------------------------------------------------------------------
Interfaces to newer FPGA's
The current vendor interfaces are ones we picked up from TMCC, so
that project did the footwork for vendor acceptable interface points.
In the 10 years since, the vendor tool chains have significantly
changed. Xilinx no longer supports XNF as a netlist format, and has
not provided a publicly documented replacement for it which interfaces
to the newest FPGAs.
While we can use EDIF to some extent as a netlist input source, what
we don't have access to is a legal description of all the library
system blocks and macros to instantiate in the EDIF netlist for newer
devices. Those library interfaces are documented inside ISE and
subject to the ISE End User License Agreement which contains a strict
Non-Disclosure agreement blocking open source use of the library
information. We can blindly use the older known library blocks to the
exent they are mapped to EDIF, but we do not have access to any of the
newer library blocks and macros as implemented for Virtex-II Pro and
Virtex-4 parts.
There is a new XDL interface which is a very attractive interface point
for FpgaC, which Xilinx now would like 3rd parties to use. However, the
documentation for XDL and the device libraries is restricted with an
NDA
which is incompatable with open source licenses. Implementing those
interfaces in open source C code, would in fact publish them to the
world
in violation of NDA restrictions, so they are currently off limits for
FpgaC.
When asking Xilinx staff what public interfaces are currently legal for
FpgaC to use to import netlists into the ISE tool chain, this question:
"But that aside, the question remains, just what, if any,
legal interfaces may open source software use to augment
the ISE tool chain? The strictest reading of the license
and NDA is clear ... NONE."
Gets this reply from Austin Lesea of Xilinx:
"I am not a lawyer.
"But it seems clear to me, when I read it: the answer is "none."
"To imply otherwise is clearly misleading, and could be interpreted
as
intentionally causing harm (to Xilinx, or its partners, or its
customers)."
So, we need to lobby Xilinx to provide a usable open source entry point
into their ISE and ISE WebPack tool chains that does not violate open
source restrictions or the NDA's in the Xilinx Licenses. Needed is a
publicly documented netlist format, such as XDL, and a set of publicly
documented library interfaces that we can call out to instantiate all
library blocks and macros for each device family, including the device
geometries for LUT's, CLB's, and other on chip objects to faciltate
FpgaC guided placement decisions or externally providing placement and
some routing information to the backend ISE tools for bit stream
generation.
Anyone providing Xilinx specific code for FpgaC needs to explore these
license issues, and make sure that we do not violate either the Xilinx
Intellectual Property (IP) rights, or the open source license(s).
Written
releases, or documented public interfaces, are required, not just for
Xilinx, but all FPGA vendor's IP.
I have been told, but have not personally explored, that we face very
similar problems with Altera. If someone could provide similar details
for their product lines and tool chains it would be greatly
appreciated,
as I do not hold a license for all the required Altera tools.
It has been suggested that some of the smaller FPGA companies are much
more eager to get open source support for the product lines, and we
will
actively support each of those that we can. If your favorite vendor
doesn't have a support path included in this release, let the FpgaC
project team know, and we will set up a project to get them supported
as soon as possible.
Article: 96037Allan Herriman <allanherriman@hotmail.com> writes: > > I walk out my front door and I look at the MCG. > When the rain doesn't obscure it.... :-)Article: 96038
Larry Doolittle wrote: > [*] No, I don't think the ISE license is, or should be, OSD-compliant. > The discussion here is whether code that I write, based on the > documentation given in ISE, can be released under an OSD-compliant > license, like BSD or GPL. The question goes far past that. Consider the BYU JHDL has XDL interfaces in it. As does the University of Massachusetts VPR for Virtex + JBits Interface project built on top of the University of Toronto work. Besides the VPR work at UofT, several other projects like EVE have XDL interfaces as well. As does the UC Berkeley work for Post-Placement C-slow Retiming. As does Peter Sutton's work JPG - A Partial Bitstream Generation Tool to Support Partial Reconfiguration in Virtex FPGAs" at UQ Australia. As does the DAGGER work done at universities in Greece. The MIT team doing 3-D Fpga architecture research was using it. The French researchers at IRIAS are doing FPGA array layouts with it. As is research and thesis work at Lund Institute of Technology, Sweden in dynamic reconfiguration. As is research and thesis work at Virginia Polytechnic Institute. As is research and thesis work at Seoul National University, Korea. As is research work at Pennsylvania State University. As is research and thesis work at UCLA. As is research and thesis work at Stanford. ... and the list goes on, and on. Many of these projects have released source and documentation which has XDL formats and xilinx device interfaces embedded. In searching, we also find that XDL is discussed in class room lectures, and is the subject of class exercises. Many of these projects describe XDL as an open interface, and treat if freely as such. That is clearly stated in many places including the Xilinx/BYU work for Los Alamos SEU project. Some of these projects include Xilinx co-authors. So, clearly the cat is out of the bag, and Xilinx should either properly protect it's IP, or just sit down and release the XDL formats and library interfaces, along with the exposed chip architectures and routing that all of the above listed projects have already fully disclosed.Article: 96039
Hi all. I must develop a software for a Digilent 2-SB (with chip Xilinx Spartan 2E) coupled with a Digilent Digital I/O 4 I decided to use Handel-C for development , but i don't know what i must study to start I downloaded manuals for both digilent devices (only 14 pages). Could you counsil me any books or links for beginners? Thanks very muchArticle: 96040
[Pardon me while I partially mix threads, I blame it on an erratic
news server. So I'm using one article as a surrogate to paste in
comments I retreived via Google. So while the author attributions
are correct, the text doesn't come from the articles listed in the
header.]
On 2006-01-28, fpga_toys@yahoo.com <fpga_toys@yahoo.com> wrote:
>
> Larry Doolittle wrote:
>> Second concern: can open source software be published that
>> works with XDL? IANAL (honest), but we have to look at this
>> from a lawyer's perspective. [chop]
>
> The answer unfortunately is that the EULA NDA restrictions and
> open source are mutually exclusive. The EULA NDA is so resrictive
> that you can not even talk to anyone about your "performance" with
> the experience as benchmarking includes everything from bugs, to
> comparitive results, to non-comparitive objective results.
While I despise terms like this in an EULA, they almost make sense
when discussing the running software itself. The most egregious
consequences come from trying to apply them to documentation, as
Xilinx's license does.
> Consider the BYU JHDL, [chop] University of Massachusetts VPR, [chop]
> UC Berkeley['s] Post-Placement C-slow Retiming, [chop] Peter Sutton's
> JPG, [chop] Greek universities [unspecified] DAGGER, [chop] IRIAS
> FPGA array layouts, [chop, plus] research and thesis work [in
> Sweden, VPI, Seul, Pennsylvania State, UCLA, Stanford, all of which
> use XDL].
That's a long list. I should spend more time with Google.
> Xilinx should either properly protect it's IP,
By pulling its head out of the sand, sending C&D letters to all
of the above projects, and posting a FAQ (oops, "answer record")
saying "No, you can't publish code that speaks XDL because of the
terms of the ISE EULA".
> or just sit down and release the XDL formats and library
> interfaces, along with the exposed chip architectures and
> routing that all of the above listed projects have already
> fully disclosed.
Whoa, where did "library interfaces" come from? Now you're talking
software, not just documentation. Drop that item from your wish
list. You'll raise fewer hackles.
The "exposed chip architectures" are very sensitive to Xilinx, but
I think they would listen to a reasoned argument that information
of that type can not be put back in the bottle. Too much of it is
already out there in the patent literature, for example.
>> One way to [resolve the confusion is for] Xilinx to post the
>> XDL documentation on-line. Why isn't it already in the "Xilinx
>> ISE 8 Software Manuals and Help"? Or maybe it is, and I'm just
>> too blind to see it?
I searched more fully, it's not there. And posting the material
(obviously NDA-free, unlike the ambiguous stuff in the ISE download)
would quickly end this discussion. I have to assume Xilinx would
like that result.
- Larry
Article: 96041shane wrote: > hi > > Thanks for replying > > iam using microblaze for first time so please bear with my questions > > iam using data width for flash device as 8 but does opb emc support > data width matching for flash devices? There is a section in the opb_emc document entitled "Data-Width Matching for Flash Memories". > > if it does support, updating the settings of system.mhs file takes > care of it or do i need to change any other settings If you are using the GUI tools, them I don't know whether changes made in the system.mhs file will get overwritten. I don't use the GUI, so I make all changes by editing that file, and that is the only place changes need to be made. > > wat values should i use for these parameters C_THZCE_PS_MEM_0, > C_TWP_PS_MEM_0 ,C_TCEDV_PS_MEM_0, C_TAVDV_PS_MEM_0, C_TWC_PS_MEM_0 You need to look at the data sheet for the flash you are using, and compare that to the definitions in the opb_emc data sheet. The values I gave as an example are only good for that particular flash.Article: 96042
Hi, sorry for a newbe question: Is there any description how to progam the configuration memory (Atmel AT45DB161B) on a Memec Virtex4 LC development board using the Xilinx platform cable USB. On the board's description there is how to program the serial flash by a PC4 cable, simlar to Xilinx xapp800. Is there any description how to do the same with the "Xilinx platform cable USB"? Many thanks, AlexArticle: 96043
"Alexander Werger" <awerger@web.de> schrieb im Newsbeitrag news:drgbd7$utt$03$1@news.t-online.com... > Hi, > sorry for a newbe question: > Is there any description how to progam the configuration memory (Atmel > AT45DB161B) on a Memec Virtex4 LC development board using the Xilinx > platform cable USB. > On the board's description there is how to program the serial flash by a > PC4 cable, simlar to Xilinx xapp800. > Is there any description how to do the same with the "Xilinx platform > cable USB"? > > Many thanks, > Alex > no there is not, and you can not do this - unless you rewrite the firmware and drivers for platform usb cable. AnttiArticle: 96044
On Fri, 27 Jan 2006 11:47:52 -0000, "Symon" <symon_brewer@hotmail.com> wrote: >I'm not sure I'd get to work too often if I had that route to travel. Is the >Gabba WiFi'd? >As for comp.arch.fpga.cricket , I notice a lot of discussion on here about >stuff like metastability in asynchronous fifos, running Linux on FPGA >processors, EULAs/IP litigation. If we can't grasp simple concepts like >that, I'm not sure we're ready to step up to the complexity of the LBW laws >just yet. >Cheers mate, Syms. All you need is "Bluff your way in Cricket" ISBN 1-85304-045-2 Philip LBW FreidinArticle: 96045
Antti Lukats wrote: > "Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag > news:drbp92$nh99@cliff.xsj.xilinx.com... > >>fpga_toys@yahoo.com wrote: >> >>> I've actually told >>>everyone who I am, and it's not that difficult to figure it out, >> >>I can't find any reference to you, so who are you then. >> >>Ed > > > Ed, > > you are right he hasnt told that, he actually told to me that I should get > used to people (like he) hiding its identify. Earlier today in this thread, 11:50 uk time. > > but if I am not mistaken then his name is: John Bass > Handles are good deflectors of casual interest. I found the discussion very interesting, and had noticed Johns name and interest before today. Jan CoombsArticle: 96046
This is also true.. but that is NOT what a C programmer calls C code ;-)
If you are going to write Boolean equations in C then you might as well use
one of the "official" languages as others can help.
my two cents :-)
Simon
P.S. I didn't see any sin functions :-)
<fpga_toys@yahoo.com> wrote in message
news:1138447086.027054.208520@o13g2000cwo.googlegroups.com...
>
> Simon Peacock wrote:
> > I think you are taking the wrong approach. I'm sure you can get the C
code
> > running. But in reality if you have to implement sin/cos & sqrts, then
the
> > C code will be far from optimal, and you might need a vertex to do the
job
> > of a Spartan
>
> Actually, I find it not that different in many cases from similar
> VHDL/Verilog
> and have the advantage of being able to tweek the output in FpgaC when
> I don't like it. Especially when I do a boolean design, it goes right
> thru FpgaC
> as boolean logic equations to the LUT. The C may look a bit ugly that
> way, but
> you certainly have nearly exact control over the output. For example:
>
> [jbass@fastbox tests]$ cat example1.c
> int a:1,b:1,c:1;
> #pragma inputport (a,a9)
> #pragma inputport (b,a10)
>
> int sum_of_products:1;
> #pragma outputport (sum_of_products,a11)
>
> main()
> {
>
> c = (sum_of_products = (a&b) + c);
> }
>
>
> produces:
>
> [jbass@fastbox tests]$ fpgac -target cnf example1.c
> [jbass@fastbox tests]$ cat example1.cnf
> _example1_Running^CLK = VCC;
> _a^CLK = port(_a,"a9");
> _b^CLK = port(_b,"a10");
> _c^(CLK*_example1_main__state_C1) = (~_c*_b*_a)+(_c*~_a)+(_c*~_b);
> port(_sum_of_products,"a11")^(CLK*_example1_main__state_C1) =
> (~_c*_b*_a)+(_c*~_a)+(_c*~_b);
> _example1_main__state_C1 = ~_example1_Running;
>
>
> which in xnf/edif is a bit more verbose (so I'll just take the meat of
> it):
>
> SYM, _sum_of_products-OBUF, OBUF
> PIN, I, I, _sum_of_products
> PIN, O, O, sum_of_products
> END
> EXT, sum_of_products, O,, LOC=_a11
> SYM, FFin-_sum_of_products, EQN, EQN=((~I0*I1*I2)+(I0*~I2)+(I0*~I1))
> PIN, I2, I, _a
> PIN, I1, I, _b
> PIN, I0, I, _c
> PIN, O, O, FFin-_sum_of_products
> END
> SYM, _sum_of_products, DFF
> PIN, D, I, FFin-_sum_of_products
> PIN, C, I, CLK
> PIN, CE, I, _example1_main__state_C1
> PIN, Q, O, _sum_of_products
> END
>
Article: 96047Jan Coombs wrote: > Antti Lukats wrote: > > you are right he hasnt told that, he actually told to me that I should get > > used to people (like he) hiding its identify. > Handles are good deflectors of casual interest. I found the discussion very > interesting, and had noticed Johns name and interest before today. It's actually been interesting to watch the petty bickering over this. The sad part is that they also told several hundred thousand other people that use handles they are not welcome to participate in this forum, as the "self appointed owners of the list" will riddicule and do everything to expose their true identiies at the slightest difference of opinion. ... totally sad as long standing usenet guidelines embrace handles.Article: 96048
I've set up a wiki space for discussion of ideas for an open source XDL tool suite. For those not familiar with wikis, they are collaborative web spaces that can be edited by anyone (for now it is editable by anyone; if there are problems we can restrict edit access to approved authors) or by a select set of individuals. They're used quite commonly for software projects now as they are great for discussion of features, todo lists, idea boards, etc. If you had tools that could parse and programatically generate XDL how would you use them? Some suggestions have been made in other recent threads here on comp.arch.fpga, now let's collect those ideas in the wikispace that I've setup here: http://thoughtfiz.stikipad.com/XDL_Tools/ There is a Feature Request page you'll see on the home page. You can go to that page and edit it or you can add comments to any page by clicking on the 'Discuss' link at the right hand side of the page. No code has yet been written. The idea here is to try to collect some ideas to see what people would want to use XDL for and then, since time is limited, determine what would give us the most 'bang for the buck' (ie. what might be the most useful features that can be achieved with a reasonable amount of programming effort). Oh, and I've also setup a page there for discussion of LegalIssues for those who are legally inclined ;-) PhilArticle: 96049
Sean Durkin wrote: > I see what you're getting at. But I'd still need to supply the ISERDES > with a 1/3-divided clock to get a 6bit-output (this is the clock the > ISERDES output is registered with). That clock I don't have, I'd need to > use a DCM or something to generate it. The sample clock on the other > hand I get from the ADCs along with the data. The whole point of using > the ISERDES is to save on clock nets, DCMs etc., and simply use what I'm > supplied with. No need for 1/3 divide. No need to use more than one clock coming back from the ADCs either, the sample clock. There are two issues with clocking, frequency and phase. The frequency is not an issue because all of your ADCs and all FPGA resources are receiving from the same clock source (I would hope). The phase issue can be broken into two parts, one of global phase, and a second of bit to bit skew across the channels. The global phase can be taken care of by using the sample clock output of one of the ADCs to feed the FPGA. As temperature changes in the system, and delays on ADC and FPGA buffers change, they will change together. This of course assumes that the ADCs in different discrete packages are subject to the same thermal conditions. The issue of bit skew across all channels can be accounted for without the ISERDES and the delay element in the IO pin. Your ADC ouputs all of the necessary test patterns to null the channel to channel skew. This calibration step would be performed at power up. You will only need one DCM in the FPGA to multiply up to your bit clock from the single ADC sample clock, to drive the ISERDES. This will also get you the proper duty cycle and phasing of the sample clock in the FPGA to make the suggestion in my previous post work. You should need one DCM and two clock nets to get this working regardless of the number of channels. Regards, Erik. --- Erik Widding President Birger Engineering, Inc. (mail) 100 Boylston St #1070; Boston, MA 02116 (voice) 617.695.9233 (fax) 617.695.9234 (web) http://www.birger.com
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