EDK : FSL macros defined by Xilinx are wrong

In article <1144487259.825320.212420@i40g2000cwc.googlegroups.com>,
burn.sir@gmail.com wrote:

Having seen way too much spam on this newsgroup lately, I have come
with a possible solution that just might work.

Add a section to FPGA FAQ where the known names on the newsgroup will
list the companies they recommend (plus some explanation). Next time
someone spams the list about "high quality PCB", or what the hell it
is, we post a polite response saying that no one should support spammer
companies and we suggest you choose another manufacture from the list
below (link to FPGA-FAQ follows).Given that spammers only care about
money, seeing they are loosing customers might stop them from spamming
the list.

This way, you will also support the local companies that you think are
doing a good job ;)


We could also add another section about newsgroup netiquette, 3leet
English and what we think about doing other peoples homework. This is
of course not as big problem as spammer, but it is still a little bit
annoying sometimes.


Furthermore, someone should contact Google, notifying them about the
existence of a group FAQ. I think the biggest problem with the FAQ is
that the ones that dont know about it are the ones that really need to
read it :)


regards
- Bruns
Considering they dont read responses, and often its via a 'bot' anyway,
i dont think it will help..

Though supporting good companies is always a good thing to do.
 
Are you including the unisims directory in the verilog simulation with
a -y option? You need to tell Verilog where the models for the BUFG
and the DCM live.

John Providenza
 
I'm assuming by that I need to put the -y option in the system.do file
that gets generated by the EDK...

If so, I'll try it and see what I can come up with. Thanks.
 
Alan Nishioka wrote:
Jeff Brower wrote:

The first FPGA has a PCI core. We were hoping to boot under 100 msec.
Is there a way to go faster than 50 MHz without resorting to external
clock + INIT gating circuitry?


I don't know. This is one of the reasons I have always used external
pci bridges. But I thought there was more time during pci config.

All I can think of is using two config proms or using parallel config
mode.
On that line, what about one of the 150Mbit Winbond SPI memories, and
a small CPLD to turn it into parallel-config ?

-jg
 
Jim Granville wrote:

Alan Nishioka wrote:

Jeff Brower wrote:

The first FPGA has a PCI core. We were hoping to boot under 100 msec.
Is there a way to go faster than 50 MHz without resorting to external
clock + INIT gating circuitry?



I don't know. This is one of the reasons I have always used external
pci bridges. But I thought there was more time during pci config.

All I can think of is using two config proms or using parallel config
mode.


On that line, what about one of the 150Mbit Winbond SPI memories, and
oops, that should be 150Mbd, of course....
 
John_H wrote:
"Fizzy" <fpgalearner@gmail.com> wrote in message
news:1144690848.814144.204880@t31g2000cwb.googlegroups.com...
...
Why do we need
clock on FPGA when our design does not have any clock input[?]
John is right of course, but to make it perfectly clear: if you have no
clocked logic, that is, all your output are combinatorial functions of
the input, then you don't need to provide a clock to your FPGA at all
and the design will still work as expected.

However, using an FPGA in such a situation would be wasting most of the
expensive machinery that is an FPGA. Maybe you only really need a CPLD.

Tommy
 
"nimayshah" <nimayshah@gmail.com> wrote in message
news:1144693869.452038.114940@z34g2000cwc.googlegroups.com...
I've compared the synthesis reports of my core
with that of xilinx coregen DA FIR V9.0. The area usage is pretty much
the same but the frequency is almost half. Also a stark difference in
the synthesis report is that my core's lut synthesizes into a Block RAM
and the Xilinx core uses nothing like that.
So my questions are:
1. What does the core use for storing LUT contents?
2. What can i do for speed optimization?
Please send in your replies as time is running out real fast.
Regards,
Nimay Shah

Hi Nimay,
Here's an answer to 2)

The BlockRAMs (BRAMS) are slower than the CLB based RAMS. Check out the
clock-to-output times for the BRAMs in the data sheet. Tcko. Or something
like that. So, use two BRAMs and interleave between them. You could use both
ports, but I guess you're using one port for dynamic loading?
Cheers, Syms.
 
Peter Winkler wrote:
Thanks for all your input.

I think it makes most sense for me to have a closer look
at PicoBlaze.

Is there a good place for PicoBlaze designs apart from the
Xilinx PicoBlaze home ? I mean some kind of community like
avrfreaks or the piclist ? A place to ask stupid newbie
questions, you know ;)

P.
Hi Peter,
if you want to use Picoblaze, then why you don't try the free C
compiler for Picoblaze?
you can download for free on www.poderico.co.uk

Next week please check on my website for the next release of the
compiler.

Best regards,
Francesco
 
I got it correctly problem was applied active low reset. Locked after
some 30 clk cycles. The lock pin is high but the edges of the clkin and
clk1x and clk2x are at different time. Why it is like that. Is this the
problem with the simulation.
 
Contact HP for licensing information. I believe they are legally required
to make available - for a reasonable price - the chips or the technology for
toner refillers and alternative suppliers. Doing so without their
permission may result in the product you produce violating copyrights or
considered black market.

<tonerchips@hotmail.com> wrote in message
news:e1fg5i01hpf@drn.newsguy.com...
hi all
i indent to make chips for toner cartridges ( specially hp ) in singapore
i need technical assistance in this regard and willing to pay reasonable
amount
for technology.
kindly let me know if anyone can help

thanks
tonerchips
 
Hi,
FPGA are already provided on-chip oscillator.
If user don't want to use ext oscillator as a clock source;he can use
internal,but the limitation is of the frequency of onchip oscillator.
Is ur question get answer?
if not then pls elaboarate more.
 
"John_H" <johnhandwork@mail.com> wrote in message
news:ddQ_f.6732$tT.3171@news01.roc.ny...
considered black market.

What about colour printers?

I'll get my coat....
 
On 8 Apr 2006 02:07:39 -0700, burn.sir@gmail.com wrote:
Having seen way too much spam on this newsgroup lately, I have come
with a possible solution that just might work.
The people that spam our news group do not read this news group.

Add a section to FPGA FAQ where the known names on the newsgroup will
list the companies they recommend (plus some explanation). Next time
someone spams the list about "high quality PCB", or what the hell it
is, we post a polite response saying that no one should support spammer
companies and we suggest you choose another manufacture from the list
below (link to FPGA-FAQ follows). Given that spammers only care about
money, seeing they are loosing customers might stop them from spamming
the list.
And they certainly don't read the FPGA FAQ at www.fpga-faq.org

This way, you will also support the local companies that you think are
doing a good job ;)

We could also add another section about newsgroup netiquette, 3leet
English and what we think about doing other peoples homework. This is
of course not as big problem as spammer, but it is still a little bit
annoying sometimes.
People with poor net hygiene don't read FAQ's either.

Furthermore, someone should contact Google, notifying them about the
existence of a group FAQ. I think the biggest problem with the FAQ is
that the ones that dont know about it are the ones that really need to
read it :)
Actually I think the real problem with the FAQ is the poor coverage
of Frequently Asked Questions. The content of the FAQ web site can be
roughly broken down into 3 pieces:

The archive of the news group (about 88.1% of all visitors, 13 GB/month)
The list of FPGA boards (about 10.4% of all visitors, 1.2 GB/month)
The FAQ questions and answers (about 0.5% of all visitors, not worth measuring)

The FAQ section has been open to anyone to write up articles that they
feel would enhance this area. There have been very few participants.

Writing good articles takes time and most of us have schedule pressures
that means that as soon as we get a resolution to a problem, we move on
to the next issue. Taking time to write it up for the FAQ is not on anyone's
radar.

Fortunately, we have the news group, which though it does not
present condensed answers to FA questions, there are enough keywords, and
high quality search engines, so that the collected wisdom can be re-used.

About 34 mainstream search engines crawl the archive per month (and generate
about 1/2 the total bandwidth), and so questions that have enough key words
often get you into the archive pretty close to a discussion on your topic.

This leads to about 3500 to 4500 visitors a day.

Anyone who would like to contribute to the FAQ section is VERY welcome,
email me with your topics!

regards
- Bruns

Philip Freidin


===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG
 
it all works (should work) with S3e, but you would still to write your
own software to handle the SPI memory

antti
 
"Antti" <Antti.Lukats@xilant.com> wrote in message
news:1144859088.483052.301100@u72g2000cwu.googlegroups.com...
it all works (should work) with S3e, but you would still to write your
own software to handle the SPI memory

antti
The information I've gathered so far suggests readback is available through
Slave Parallel or JTAG modes. I don't seem to find internal readback
capability. To read back through the JTAG port, I'd expect to have to
interface to the JTAG pins externally through four other I/O.

Can I configure with Slave Serial and do the readback through JTAG?

If I'm trying to do this on board as opposed to through the Xilinx tool
suite I don't see how "it all works" with the info I've perused so far.
 
John_H wrote:
The information I've gathered so far suggests readback is available through
Slave Parallel or JTAG modes. I don't seem to find internal readback
capability.
To read or write the SPI eeprom after config, you bit-bang the SPI pins
from the fpga like any other IO pin. All of the SPI pins are general
purpose IO pins.

Or perhaps I don't understand the question.

Alan Nishioka
 
"Alan Nishioka" <alan@nishioka.com> wrote in message
news:1144865199.566139.147490@u72g2000cwu.googlegroups.com...
John_H wrote:
The information I've gathered so far suggests readback is available
through
Slave Parallel or JTAG modes. I don't seem to find internal readback
capability.

To read or write the SPI eeprom after config, you bit-bang the SPI pins
from the fpga like any other IO pin. All of the SPI pins are general
purpose IO pins.

Or perhaps I don't understand the question.

Alan Nishioka
To bit-bang the SPI pins through external software that's used to
configuring FPGAs through Slave Serial configuration, a new software driver
that's SPI NAND capable would heve to be developed to provide "new" bit
banging. If I left it in the hardware realm, reprogramming the SPI based on
the FPGA's *own configuration* would be desirable, leaving the NAND
programming details to me in the hardware.

My need becomes reading back the configuration from the device itself by the
device while the device is operating.
 
John_H wrote:
If I left it in the hardware realm, reprogramming the SPI based on
the FPGA's *own configuration* would be desirable, leaving the NAND
programming details to me in the hardware.

My need becomes reading back the configuration from the device itself by the
device while the device is operating.
So you want to have an fpga read its own configuration from itself and
program an SPI eeprom? Won't that allow it to program itself, and
eventually take over the planet?

Isn't a lot of information missing from such a readback, such as all
the register init states and the bram init?

Alan Nishioka
 
I think you have totally missed the point. posting a link to the FAQ in
answer to questions is (1) smarter if the same question pops every now
and then (2) makes it show up less often in future (3) can give a more
comprehensive answer (4) makes more people aware of the FAQ.
It works like this in many other groups, and it works rather nice for
Mike Treseler in this newsgroup too :)


about the spam part, well... if you start posting things that hurts
their business, believe me they gonna notice.

and even if they dont, it is still better to have a list of good
suppliers at hand




People with poor net hygiene don't read FAQ's either.
Saying that was very stupid of you.




Back to the subject. In either case, it is always nice if people
contribute and try to extend the FAQ.

Bruns
 

Welcome to EDABoard.com

Sponsor

Back
Top