Any example Master Ports available?

Hi Ken,

Just so you (and others) know, there is no difference in having user-logic inside the SOPC Builder system versus connected at the top level. Both approaches should synthesize to the same resultant logic. What I sent you, with the class.ptf file, just packages up some HDL code and tells SOPC Builder how to hook up each port - just as one would do manually in the interface-to-user-logic GUI.

As I stated to you personally, that GUI is undergoing an overhaul and will have cababilities for more complex user-logic in the future.

I am, however, tinkering with a design in my spare time that should be more applicable to your needs...

--- Quote Start ---

originally posted by kenland+jul 13 2004, 06:01 pm--><div class='quotetop'>quote (kenland @ jul 13 2004, 06:01 pm)</div>

--- quote start ---

the data is coming from an adc at one 32 bit word every 570ns. the max it would ever be is 2mhz.[/b]

--- quote end ---

so this adc&#39;s clock is much slower than the system clock and the data rate is pretty constant. transactions will look like a 32-bit write to ram every now and then, so you don&#39;t really need the dma avalon signals. i&#39;ll assume that you&#39;re properly synchronizing the adc signals to the avalon clock before proceeding. at that speed, all you really have to do is write a small state machine to grab a sample, then put it on the avalon bus, no pipelining needed.

--- quote start ---

Originally posted by KenLand[/i]@

since it works at a lower fmax and we&#39;re not really burdening the system that much i&#39;m kinda lost.

--- Quote End ---

That just sounds like a cycle/clock timing problem to me, as in jumping clock domains, not exceeding fmax.

<!--QuoteBegin-KenLand[/i]

i kinda suspect that the build process optimizes the conection between our external logic and the avalon/sdram to the extent that they are too intermingled. we don&#39;t have any of this problem with logic that is actually outside the cyclone chip. (where logical interfaces *must* be adhered to)

--- Quote End ---

Put your logic in a LogicLock region, variable size, and optionally put the SOPC module in another one. That should keep them apart.

BTW, how are you dealing with waitrequest from the Avalon?

Hi Jesse,

Thanks for the help. I think I&#39;m the proverbial software guy that Altera is targeting. If you can make it easy enough for me then you&#39;ve hit the target!

You (Altera) are already very close as I can&#39;t believe how close a very complex project came to being completed in just a month or two. (We&#39;ve been on it a total 13mo.s but custom boards didn&#39;t arrive until Jan &#39;04)

If we woudn&#39;t have hit this snag with inputting a data stream, we&#39;d be shipping product! (or at least be duking it out with TUV and NTI http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif )

Just send anything you think is close and I&#39;ll try to run with it. Once I get it going I&#39;ll post it here on the forum for all. (unless you prefer to do it)

Can&#39;t wait to see your new GUI to IUL!

Mike,

All clocking for the ADC operation is derived from the CPUCLK simply by counting the correct number to make things happen on time.

Your analysis of system impact matches mine and we&#39;re perplexed as to why its a problem. It&#39;s simply a memory write every now and again.

I think it may be a fundamental lack of hardware experience that is producing unintended timing dependencies between the port and our logic block. The timing analyzer does complain, but I&#39;m not sure what do do about it. For example the only logic connected to the address port is an lpm_counter that gets loaded with the sdram buffer address and then increments 4 times for each 32 bit word. Write_n is registered on CPUCLK and either waits until wait_request is not active on a following rising clock. The Avalon spec. seems easy enough to follow and the Logic analyzer shows what appears to be textbook operation, but yet it doesn&#39;t operate perfectly at high CPUCLKs.

Do you think it can be the timing violations even though the LA looks fine?

Kerri,

Have you had a chance to look at my project or pass it on? My Arrow FAE said his end was progressing, but I imagine you&#39;re closer to SOPC gurus. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

Thanks All!

Ken

Sent it along (twice, once again today). And yes, I&#39;m closer. I sit next to them :-)

We&#39;re just always busy here. But we&#39;re trying...

--- Quote Start ---

originally posted by kenland+jul 14 2004, 06:41 pm--><div class='quotetop'>quote (kenland @ jul 14 2004, 06:41 pm)</div>

--- quote start ---

the timing analyzer does complain, but i&#39;m not sure what do do about it.[/b]

--- quote end ---

what are its specific complaints?

--- quote start ---

originally posted by kenland@jul 14 2004, 06:41 pm

for example the only logic connected to the address port is an lpm_counter that gets loaded with the sdram buffer address and then increments 4 times for each 32 bit word.

--- quote end ---

umm... four times? why not just increment by four? drive address[n-1:2] from the counter and drive address[1:0] with 0?

--- quote start ---

originally posted by kenland@jul 14 2004, 06:41 pm

write_n is registered on cpuclk and either waits until wait_request is not active on a following rising clock.

--- quote end ---

you&#39;re supposed to keep write_n driven, not gate it with waitrequest. the write cycle starts when you want it to; this isn&#39;t like a shared bus where you have to wait for the other guy to get off of it. (well, actually, you do, but you wait by asserting write_n and waiting for waitrequest to go low. there&#39;s no separate wait-for-bus-release step.)

<!--quotebegin-kenland@Jul 14 2004, 06:41 PM

do you think it can be the timing violations even though the la looks fine?

--- Quote End ---

It could be. Could you post just the ADC-to-Avalon master interface code?

Hi Mike,

Thank for your help.

I tried the incrementing the address as you say and tying the bottom two bits low. No change. (this was one of the first things I tried weeks ago)

I probably wasn&#39;t clear on WEn. It&#39;s not registered with wait_request, but the CPUCLK. WEn is dependent on wait_request though since WEn cannot deassert until the next rising edge where wait_request is not asserted. (We&#39;ve also tried the interpretation that WEn asserts as long as necessary for wait_request to assert and to deassert before WEn deasserts.)

Here is a puzzling timing violation. It complains about negative slack FROM lpm_counter|...|lpm_counter_stratix:wysi_counter|pre_hazard[0]~28 TO sdram:the_sdram|sdram_input_efifo_module|entry_1[1] From Clock alt_pll|clk0 To alt_pll|clk0.

Very confusing since there is at least two latches inbetween the output of this counter and the input to the SOPC system and thus on to sdram.

I can&#39;t imagine that anyone cares about whats on the other side of a latch that is registered to the CPUCLK. (?) Shouldn&#39;t anyone reading the latches output simply get what&#39;s there at the time of the read?

This don&#39;t care attitude seems to be what I&#39;m working with for any external-to-the-cyclone peripheral. I simply present the proper signals in proper sequence and everyone is happy. On this internal-to-the-Cyclone peripheral however there is something more obscure going on.

I recently registered all in and out signals from the Master Port right at the Master Port in an attempt to compartmentalize the operations, but as you see in the warnings the build process is making obscure connections. And I don&#39;t doubt the warnings indicate real problems because lowering fmax to what it says is legal results in proper operation. (ie system doesn&#39;t lock up)

It&#39;s not a system overload issue, because I can generate all of this data (test data) within one of my Nios CPUs and no problems whatsoever.

If I had any pins left I&#39;d connect the two modules through an external path, but I don&#39;t. There must be some fpga 101 rule that we&#39;re violating?

Kerri,

Any feedback from the SOPC engineers?

Thanks,

Ken