Excuse me for a very long gap that I was absent.

On Tue, 18 Aug 2015 21:40:27 -0400, Richard Damon wrote:

> On 8/18/15 11:35 AM, rickman wrote:
>> I'm not sure what details of the routing the chip editors leave out.
>> You only need to know what is connected to what, through what and what
>> the delays for all those cases are.  Other than that, the routing does
>> just "work".
>>
> Look closely. [...] Those rows and columns are made of a
> (large) number of distinct wires with routing resources connecting
> outputs to select lines and select lines being brought into the next
> piece of routing/logic. Which wire is being used will not be indicated,
> nor are all the wires interchangeable, so which wire can matter for
> fitting. THIS is the missing information.

A comment:

All this information sounds like it can be teased out of the physical 
chips. But, I find there are other considerations. First, doing this 
might jeopardize the FPGA manufacturer. It's no good to have a FOSS 
toolchain but no FPGAs to use it on. Second, there is the problem of a 
FPGA manufacturer releasing a small tweak that would invalidate the 
entire work done. Third, and this is where it gets interesting, the time 
and effort spent reverse-engineering a great number of FPGA models is 
probably better spent engineering a FOSH ASIC toolchain together with the 
assorted manufacturing technology. Because - honestly - if you are 
willing to program FPGAs, you are really not very far away from forging 
ASICs, are you?

Speaking for myself, I'm working alone on FPGAs far away from silicon 
powerhouses and I have to jump through hoops and loops to get the chips. 
Jumping through hoops and loops to get my design forged into an ASIC is 
not really that different.

On 8/18/2015 9:40 PM, Richard Damon wrote:
> On 8/18/15 11:35 AM, rickman wrote:
>> On 8/15/2015 8:32 AM, Richard Damon wrote:
>>>
>>> The chip editors tend to just show the LOGIC resources, not the details
>>> of the routing resources. The manufactures tend to do a good job of
>>> giving the detail of the logic blocks you are working with, as this is
>>> the part of the design you tend to specify. Routing on the other hand
>>> tends to not be something you care about, just that the routing 'works'.
>>> When they have done a good job at designing the routing you don't notice
>>> it, but there have been cases where the routing turned out not quite
>>> flexible enough and you notice that you can't fill the device as well
>>> before hitting routing issues.
>>
>> I'm not sure what details of the routing the chip editors leave out. You
>> only need to know what is connected to what, through what and what the
>> delays for all those cases are.  Other than that, the routing does just
>> "work".
>>
>
> Look closely. The chip editor will normally show you the exact logic
> element you are using with a precise location. The output will then go
> out into a routing channel and on the the next logic logic cell(s) that
> it goes to. It may even show you the the various rows and columns of
> routing it is going through. Those rows and columns are made of a
> (large) number of distinct wires with routing resources connecting
> outputs to select lines and select lines being brought into the next
> piece of routing/logic. Which wire is being used will not be indicated,
> nor are all the wires interchangeable, so which wire can matter for
> fitting. THIS is the missing information.

I can't speak with total authority since I have not used a chip editor 
in a decade.  But when I have used them they showed sufficient detail 
that I could control every aspect of the routing.  In fact, it showed 
every routing resource in sufficient detail that the logic components 
were rather small and were a bit hard to see.

When you say which wire is used is not shown, how would you be able to 
do manual routing if the details are not there?  Manual routing and 
logic is the purpose of the chip editors, no?


>>>>> I have had to work with the factory on things like this. I had a very
>>>>> full FPGA and needed to make a small change. With the change I had
>>>>> some
>>>>> over clogged routing, but if I removed all internal constraints the
>>>>> fitter couldn't find a fit. Working with someone who did know the
>>>>> details, we were able to relax just a few internal constraints and get
>>>>> the system to fit the design. He did comment that my design was
>>>>> probably
>>>>> the fullest design he had seen in the wild, we had grown to about 95%
>>>>> logic utilization.
>>>>
>>>> Yeah, that's pretty full.  I start to worry around 80%, but I've never
>>>> actually had one fail to route other than the ones I tried to help by
>>>> doing placement, lol.
>>>>
>>>
>>> They suggest that you consider 75-80% to be "Full". This design started
>>> in the 70% level but we were adding capability to the system and the
>>> density grew. (And were already using the largest chip for the
>>> footprint). Our next step was to redo the board and get the usage back
>>> down. When we hit the issue we had a mostly working design but were
>>> fixing the one last bug, and that was when the fitter threw its fit.
>>
>> The "full" utilization number is approximate because it depends on the
>> details of the design.  Some designs can get to higher utilization
>> numbers, others less.  As a way of pointing out that the routing is the
>> part of the chip that uses the most space while the logic is smaller,
>> Xilinx sales people used to say, "We sell you the routing and give you
>> the logic for free."  The point is the routing usually limits your
>> design rather than the logic.  If you want to be upset about utilization
>> numbers, ask them how much of your routing gets used!  It's *way* below
>> 80%.
>>
> And this is why the keep the real details of the routing proprietary.
> (Not to keep you from getting upset) The serious design work goes into
> figuring out how much they really need per cell. If they could figure
> out a better allocation that let them cut the routing per cell by 10%,
> they could give you 10% more logic for free. If they goof and provide
> too little routing, you see the resources that you were sold (since they
> advertize the logic capability) as being wasted by some 'dumb design
> limitation'. There have been families that got black eyes of having
> routing problems, and thus should be avoided for 'serious' work.

I don't follow the logic.  There are always designs that deviate from 
the typical utilization in both directions.  Whether you can see what 
details in the chip editor has nothing to do with user satisfaction 
since you can read the utilization numbers in the reports and don't need 
to see any routing, etc.

-- 

Rick

On 8/18/2015 2:21 PM, KJ wrote:
> On Tuesday, August 18, 2015 at 11:35:55 AM UTC-4, rickman wrote:
>>
>> I'm not sure what details of the routing the chip editors leave out.
>> You only need to know what is connected to what, through what and what
>> the delays for all those cases are.
>
> If you're trying to implement an open source toolchain you would likely need to know *how* to specify those connections via the programming bitstream.

Well... yeah.  That's the sticky wicket, knowing how to generate the 
bitstream.  I think you missed the point of this subthread.

-- 

Rick

On 8/18/15 11:35 AM, rickman wrote:
> On 8/15/2015 8:32 AM, Richard Damon wrote:
>>
>> The chip editors tend to just show the LOGIC resources, not the details
>> of the routing resources. The manufactures tend to do a good job of
>> giving the detail of the logic blocks you are working with, as this is
>> the part of the design you tend to specify. Routing on the other hand
>> tends to not be something you care about, just that the routing 'works'.
>> When they have done a good job at designing the routing you don't notice
>> it, but there have been cases where the routing turned out not quite
>> flexible enough and you notice that you can't fill the device as well
>> before hitting routing issues.
>
> I'm not sure what details of the routing the chip editors leave out. You
> only need to know what is connected to what, through what and what the
> delays for all those cases are.  Other than that, the routing does just
> "work".
>

Look closely. The chip editor will normally show you the exact logic 
element you are using with a precise location. The output will then go 
out into a routing channel and on the the next logic logic cell(s) that 
it goes to. It may even show you the the various rows and columns of 
routing it is going through. Those rows and columns are made of a 
(large) number of distinct wires with routing resources connecting 
outputs to select lines and select lines being brought into the next 
piece of routing/logic. Which wire is being used will not be indicated, 
nor are all the wires interchangeable, so which wire can matter for 
fitting. THIS is the missing information.
>
>>>> I have had to work with the factory on things like this. I had a very
>>>> full FPGA and needed to make a small change. With the change I had some
>>>> over clogged routing, but if I removed all internal constraints the
>>>> fitter couldn't find a fit. Working with someone who did know the
>>>> details, we were able to relax just a few internal constraints and get
>>>> the system to fit the design. He did comment that my design was
>>>> probably
>>>> the fullest design he had seen in the wild, we had grown to about 95%
>>>> logic utilization.
>>>
>>> Yeah, that's pretty full.  I start to worry around 80%, but I've never
>>> actually had one fail to route other than the ones I tried to help by
>>> doing placement, lol.
>>>
>>
>> They suggest that you consider 75-80% to be "Full". This design started
>> in the 70% level but we were adding capability to the system and the
>> density grew. (And were already using the largest chip for the
>> footprint). Our next step was to redo the board and get the usage back
>> down. When we hit the issue we had a mostly working design but were
>> fixing the one last bug, and that was when the fitter threw its fit.
>
> The "full" utilization number is approximate because it depends on the
> details of the design.  Some designs can get to higher utilization
> numbers, others less.  As a way of pointing out that the routing is the
> part of the chip that uses the most space while the logic is smaller,
> Xilinx sales people used to say, "We sell you the routing and give you
> the logic for free."  The point is the routing usually limits your
> design rather than the logic.  If you want to be upset about utilization
> numbers, ask them how much of your routing gets used!  It's *way* below
> 80%.
>
And this is why the keep the real details of the routing proprietary. 
(Not to keep you from getting upset) The serious design work goes into 
figuring out how much they really need per cell. If they could figure 
out a better allocation that let them cut the routing per cell by 10%, 
they could give you 10% more logic for free. If they goof and provide 
too little routing, you see the resources that you were sold (since they 
advertize the logic capability) as being wasted by some 'dumb design 
limitation'. There have been families that got black eyes of having 
routing problems, and thus should be avoided for 'serious' work.

On Tuesday, August 18, 2015 at 11:35:55 AM UTC-4, rickman wrote:
> 
> I'm not sure what details of the routing the chip editors leave out. 
> You only need to know what is connected to what, through what and what 
> the delays for all those cases are.

If you're trying to implement an open source toolchain you would likely need to know *how* to specify those connections via the programming bitstream.

Kevin

On 8/15/2015 8:32 AM, Richard Damon wrote:
> On 8/14/15 10:59 PM, rickman wrote:
>> On 8/14/2015 9:32 PM, Richard Damon wrote:
>>>
>>> My experience is that you get to see what location a given piece of
>>> logic, and which channels it travels. You do NOT see which particular
>>> wire in that channel is being used. In general, each logic cell does not
>>> have routing to every wire in that channel, and every wire does not have
>>> access to every cross wire. These details tend to be the secret sauce,
>>> as when they do it well, you aren't supposed to notice the incomplete
>>> connections.
>>
>> Don't they still have the chip editor?  That *must* show everything of
>> importance.
>
> The chip editors tend to just show the LOGIC resources, not the details
> of the routing resources. The manufactures tend to do a good job of
> giving the detail of the logic blocks you are working with, as this is
> the part of the design you tend to specify. Routing on the other hand
> tends to not be something you care about, just that the routing 'works'.
> When they have done a good job at designing the routing you don't notice
> it, but there have been cases where the routing turned out not quite
> flexible enough and you notice that you can't fill the device as well
> before hitting routing issues.

I'm not sure what details of the routing the chip editors leave out. 
You only need to know what is connected to what, through what and what 
the delays for all those cases are.  Other than that, the routing does 
just "work".


>>> I have had to work with the factory on things like this. I had a very
>>> full FPGA and needed to make a small change. With the change I had some
>>> over clogged routing, but if I removed all internal constraints the
>>> fitter couldn't find a fit. Working with someone who did know the
>>> details, we were able to relax just a few internal constraints and get
>>> the system to fit the design. He did comment that my design was probably
>>> the fullest design he had seen in the wild, we had grown to about 95%
>>> logic utilization.
>>
>> Yeah, that's pretty full.  I start to worry around 80%, but I've never
>> actually had one fail to route other than the ones I tried to help by
>> doing placement, lol.
>>
>
> They suggest that you consider 75-80% to be "Full". This design started
> in the 70% level but we were adding capability to the system and the
> density grew. (And were already using the largest chip for the
> footprint). Our next step was to redo the board and get the usage back
> down. When we hit the issue we had a mostly working design but were
> fixing the one last bug, and that was when the fitter threw its fit.

The "full" utilization number is approximate because it depends on the 
details of the design.  Some designs can get to higher utilization 
numbers, others less.  As a way of pointing out that the routing is the 
part of the chip that uses the most space while the logic is smaller, 
Xilinx sales people used to say, "We sell you the routing and give you 
the logic for free."  The point is the routing usually limits your 
design rather than the logic.  If you want to be upset about utilization 
numbers, ask them how much of your routing gets used!  It's *way* below 
80%.

-- 

Rick

On 8/14/15 10:59 PM, rickman wrote:
> On 8/14/2015 9:32 PM, Richard Damon wrote:
>>
>> My experience is that you get to see what location a given piece of
>> logic, and which channels it travels. You do NOT see which particular
>> wire in that channel is being used. In general, each logic cell does not
>> have routing to every wire in that channel, and every wire does not have
>> access to every cross wire. These details tend to be the secret sauce,
>> as when they do it well, you aren't supposed to notice the incomplete
>> connections.
>
> Don't they still have the chip editor?  That *must* show everything of
> importance.

The chip editors tend to just show the LOGIC resources, not the details 
of the routing resources. The manufactures tend to do a good job of 
giving the detail of the logic blocks you are working with, as this is 
the part of the design you tend to specify. Routing on the other hand 
tends to not be something you care about, just that the routing 'works'. 
When they have done a good job at designing the routing you don't notice 
it, but there have been cases where the routing turned out not quite 
flexible enough and you notice that you can't fill the device as well 
before hitting routing issues.
>
>
>> I have had to work with the factory on things like this. I had a very
>> full FPGA and needed to make a small change. With the change I had some
>> over clogged routing, but if I removed all internal constraints the
>> fitter couldn't find a fit. Working with someone who did know the
>> details, we were able to relax just a few internal constraints and get
>> the system to fit the design. He did comment that my design was probably
>> the fullest design he had seen in the wild, we had grown to about 95%
>> logic utilization.
>
> Yeah, that's pretty full.  I start to worry around 80%, but I've never
> actually had one fail to route other than the ones I tried to help by
> doing placement, lol.
>

They suggest that you consider 75-80% to be "Full". This design started 
in the 70% level but we were adding capability to the system and the 
density grew. (And were already using the largest chip for the 
footprint). Our next step was to redo the board and get the usage back 
down. When we hit the issue we had a mostly working design but were 
fixing the one last bug, and that was when the fitter threw its fit.

On 8/14/2015 9:32 PM, Richard Damon wrote:
> On 8/14/15 1:29 PM, rickman wrote:
>> On 8/13/2015 11:17 PM, Richard Damon wrote:
>>>
>>> One big factor against an open source tool chain is that while the FPGA
>>> vendors describe in general terms the routing inside the devices, the
>>> precise details are not given, and I suspect that these details may be
>>> considered as part of the "secret sauce" that makes the device work. The
>>> devices have gotten so big and complicated, that it is impractical to
>>> use fully populated muxes, and how you chose what gets to what is
>>> important.
>>
>> I'm not sure what details of routing aren't available.  There  may not
>> be a document which details it all, but last I saw, there were chip
>> level design tools which allow you to see all of the routing and
>> interconnects.  The delay info can be extracted from the timing analysis
>> tools.  As far as I am aware, there is no "secret sauce".
>>
>>
>>> Processors can also have little details like this, but for processors it
>>> tends to just affect the execution speed, and a compiler that doesn't
>>> take them into account can still do a reasonable job. For an FPGA,
>>> without ALL the details for this you can't even do the routing.
>>
>> Timing data in an FPGA may be difficult to extract, but otherwise I
>> think all the routing info is readily available.
>>
>
> My experience is that you get to see what location a given piece of
> logic, and which channels it travels. You do NOT see which particular
> wire in that channel is being used. In general, each logic cell does not
> have routing to every wire in that channel, and every wire does not have
> access to every cross wire. These details tend to be the secret sauce,
> as when they do it well, you aren't supposed to notice the incomplete
> connections.

Don't they still have the chip editor?  That *must* show everything of 
importance.


> I have had to work with the factory on things like this. I had a very
> full FPGA and needed to make a small change. With the change I had some
> over clogged routing, but if I removed all internal constraints the
> fitter couldn't find a fit. Working with someone who did know the
> details, we were able to relax just a few internal constraints and get
> the system to fit the design. He did comment that my design was probably
> the fullest design he had seen in the wild, we had grown to about 95%
> logic utilization.

Yeah, that's pretty full.  I start to worry around 80%, but I've never 
actually had one fail to route other than the ones I tried to help by 
doing placement, lol.

-- 

Rick

On 8/14/15 1:29 PM, rickman wrote:
> On 8/13/2015 11:17 PM, Richard Damon wrote:
>>
>> One big factor against an open source tool chain is that while the FPGA
>> vendors describe in general terms the routing inside the devices, the
>> precise details are not given, and I suspect that these details may be
>> considered as part of the "secret sauce" that makes the device work. The
>> devices have gotten so big and complicated, that it is impractical to
>> use fully populated muxes, and how you chose what gets to what is
>> important.
>
> I'm not sure what details of routing aren't available.  There  may not
> be a document which details it all, but last I saw, there were chip
> level design tools which allow you to see all of the routing and
> interconnects.  The delay info can be extracted from the timing analysis
> tools.  As far as I am aware, there is no "secret sauce".
>
>
>> Processors can also have little details like this, but for processors it
>> tends to just affect the execution speed, and a compiler that doesn't
>> take them into account can still do a reasonable job. For an FPGA,
>> without ALL the details for this you can't even do the routing.
>
> Timing data in an FPGA may be difficult to extract, but otherwise I
> think all the routing info is readily available.
>

My experience is that you get to see what location a given piece of 
logic, and which channels it travels. You do NOT see which particular 
wire in that channel is being used. In general, each logic cell does not 
have routing to every wire in that channel, and every wire does not have 
access to every cross wire. These details tend to be the secret sauce, 
as when they do it well, you aren't supposed to notice the incomplete 
connections.

I have had to work with the factory on things like this. I had a very 
full FPGA and needed to make a small change. With the change I had some 
over clogged routing, but if I removed all internal constraints the 
fitter couldn't find a fit. Working with someone who did know the 
details, we were able to relax just a few internal constraints and get 
the system to fit the design. He did comment that my design was probably 
the fullest design he had seen in the wild, we had grown to about 95% 
logic utilization.

On 8/13/2015 11:17 PM, Richard Damon wrote:
> On 8/13/15 9:44 PM, thomas.entner99@gmail.com wrote:
>>> Again SDCC has few
>>> developers, and at least recently, the most active ones don't seem that
>>> interested in the pics.
>>>
>> Back to the topic of the open FPGA tool chain, I think there would
>> bemany "PICs", i.e. topics which are addressed by no / too few
>> developers.
>>
>> But the whole discussion is quite theoretical as long as A & X do
>> not  open their bitstream formats. And I do not think that they will do
>> anything that will support an open source solution, as software is the
>> main entry obstacle for FPGA startups. If there would be a flexible
>> open-source tool-chain with large developer and user-base that can be
>> ported to new architectures easily, this would make it much easier for
>> new competition. (Think gcc...)
>>
>> Also (as mentioned above) I think with the good and free tool chains
>> from the suppliers, their would be not much demand for such a open
>> source tool chain. There are other points where I would see more
>> motiviation and even there is not happening much:
>> - Good open source Verilog/VHDL editor (Yes, I have heard of
>> Emacs...)
>> as the integrated editors are average (Altera) or bad (Xilinx).
>> (Currently I am evaluating two commercial VHDL editors...)
>> - A kind of graphical editor for VHDL and Verilog as the top/higher
> levels of bigger projects are often a pain IMHO (like writing netlists
> by hand). I would even start such a project myself if I had the time...
>>
>> But even with such things where I think would be quite some demand,
>> the "critical mass" of the FPGA community is too low to get projects
>> started and especially keep them running.
>>
>> Thomas
>>
>
> One big factor against an open source tool chain is that while the FPGA
> vendors describe in general terms the routing inside the devices, the
> precise details are not given, and I suspect that these details may be
> considered as part of the "secret sauce" that makes the device work. The
> devices have gotten so big and complicated, that it is impractical to
> use fully populated muxes, and how you chose what gets to what is
> important.

I'm not sure what details of routing aren't available.  There  may not 
be a document which details it all, but last I saw, there were chip 
level design tools which allow you to see all of the routing and 
interconnects.  The delay info can be extracted from the timing analysis 
tools.  As far as I am aware, there is no "secret sauce".


> Processors can also have little details like this, but for processors it
> tends to just affect the execution speed, and a compiler that doesn't
> take them into account can still do a reasonable job. For an FPGA,
> without ALL the details for this you can't even do the routing.

Timing data in an FPGA may be difficult to extract, but otherwise I 
think all the routing info is readily available.

-- 

Rick