Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Need salvation~~

Hi, all:

I'm really frustrated today. After a long period effort, it seems I made little progress.

Problems always occur when you think you're ready, and sometimes the problem turns out to be vital. My current design may be a failure which I don't wanna admit.

Maybe the way I do isn't proper. Or maybe the bad luck (actually, this is self-consolation). I did something on Xilinx platform before, so there's some basic knowledge on FPGA (however, I did learn it by myself and my previous major was not the field like FPGA). Now I realize it's a long way to run.

I wanna take anyone who can offer me some advices on the improvement on FPGA. Like when you are starting to do a brand new project, how can you schedule to avoid some stupid problems. Like from where to learn is a better way, for example, you can start coding or start familiaring with the device, but somehow, different ways may have different results. Like when you use a new device with some knowledge of other vendor's products, what should you do first to migrant your mind.

Also, if you can recommend some books on hardware and software co-designing, it will do good to me.

Thank you for bearing my compliants and silly questions. Looking forward to the beacon.

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Ninos,

    Probably the best way to gain understanding is through example designs and simulations / working with dev kits. It seems that you have sufficient experience such that books will only take you so far; 'doing' is often better - this isn't Fourier analysis.

    Since your asking about co-design, I recommend working through some simpler Nios II designs that include a simulation component.

    Perhaps the verification IP examples:

    search for this "example design nios simulation" within the Altera site. I haven't posted enough to add links... no trust ... nice. Plenty of examples tie an SoC together using simulation.

    Just some thoughts, your topic is a bit broad.

    -Jerry
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hi, Jerry:

    Simulation is a good way while "doing" is better, like you said. Also, team-work matters a lot. However, what I really expect is the strategy or tactics for project development. Yeah, it's too big and a bit obscure.:) Anyway, thank you very much for your advices.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    My advice is: start small and work your way up. So when learning the ins and outs don't try to learn concepts from a huge design since you'll loose the tree in the forest. This is my approach to design as well, I prefer to design small pieces with nice standard interfaces, then assemble them into something larger. This approach scales for team based design approaches since you can have an 'architect' engineer overseaing the project while individuals implementing bits and pieces of the final objective.

    We can probably give more advice if we knew what kind of project you have in mind (embedded, DSP, high speed switching, etc...)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hi, BadOmen:

    Thank you very much for the advice.

    Our project is rather simple: we capture 6 channels data simutaneouly using FPGA, do a little processing inside FPGA, then reshape the format of the data and send them out to DSP. What I found frustrating is the mismatch of PCB design and software (here I mean verilog coding, not higer level language); these two parts of work are done by two men. Since the PCB is already, some effort must be taken by coding and change of structure which is painful.

    Absence of the "achitect engineer" have some effect on the current situation. However, next time I'd rather do the software first.